Possible translation solution #285
Conversation
…l/de_DE/ for german translation messages
Took the LINGUAS file from darktable so that the lua-scripts translations are for the same languages as darktable. Created a data/po directory to contain the translation files. Decided to keep the one file per script instead of one huge file. That way the scripts can be translated one at a time if necessary keeping the work small and manageable. The locale directory now contains a directory for each language contained in the LINGUAS file. Underneath that is an LC_MESSAGES directory and under that a scripts.mo file. To automate maintenance of the translations I created some tools tools/create_potfiles.sh is a bash script run from the data/po directory that scans all the scripts looking for the bindtextdomain keyword and adding the script filename to the POTFILES.in file. tools/update_po_files.sh creates the translation po file for a script, in all the language directories, for a script if it doesn't have a po file. If the po file is already there, then any new changes are merged with the existing po file. tools/fix_header.sh changes the PACKAGE, CHARSET, and Language fields in the po file to darktable lua-scripts, UTF-8, and the language code. tools/create_mo.sh merges the translation po files into one file and then creates the binary mo file from that.
|
Maybe fixes #244 |
is modified or a translation file is modified. For the first scenario I combined tools/create_potfiles.sh, tools/fix_header.sh, and tools/update_po_files.sh into tools/update_translations.sh. So, when a script file is updated then tools/update_translations.sh and tools/create_mo.sh need to be run. When only a transltion file is updated, then just tools/create_mo.sh need to be run.
|
Reduced the scenarios to just 2, create/update a script file, or update a translation file. In the first case, now we just run tools/update_translations.sh and tools/create_mo.sh. In the second case we just run tools/create_mo.sh. Now I have a question/thought about what we should translate. I think that all the strings the user sees as part of running the script in a normal fashion should be translated. I'm not so sure the darktable.print_log and darktable.print_error messages should be translated. In my case I'm a native english speaker and, while I can swear and order food and drink in several languages, that really doesn't help if a user runs with darktable with -d lua and I get debugging messages in a different language. On the other hand, it may help the user solve their own problem. I can always reverse translate if I have to, but it would take time. Thoughts? |
|
One more thought and whether to translate debugging messages or not... darktable does not translate error/debugging messages. |
When I updated the translation files, all of them updated which wasn't what I wanted to happen. Added a check to only update files when the script file is newer than the translation file or create the translation file if it doesn't exist. Corrected a bug where the translation file header fix ran before the update.
|
I would not translate debugging messages. It makes it much more easy to search for the error. An alternative would be an translated error message with an error number. |
…derscore in _(<message to translate>) causing an error.
|
@TurboGit I started this awhile ago, but wasn't really sure where to go with it. You have way more experience with translations than I do, so any suggestions would be welcome. |
|
This has been superseded by #450 |
THIS IS A WORK IN PROGRESS!!
Took the LINGUAS file from darktable so that the lua-scripts translations are for the same languages as darktable.
Created a data/po directory to contain the translation files. Decided to keep the one file per script instead of one huge file. That way the scripts can be translated one at a time if necessary keeping the work small and manageable.
The locale directory now contains a directory for each language contained in the LINGUAS file. Underneath that is an LC_MESSAGES directory and under that a scripts.mo file.
To automate maintenance of the translations I created some tools
tools/create_potfiles.sh is a bash script run from the data/po directory that scans all the scripts looking for the bindtextdomain keyword and adding the script filename to the POTFILES.in file.
tools/update_po_files.sh creates the translation po file for a script, in all the language directories, for a script if it doesn't have a po file. If the po file is already there, then any new changes are merged with the existing po file.
tools/fix_header.sh changes the PACKAGE, CHARSET, and Language fields in the po file to darktable lua-scripts, UTF-8, and the language code.
tools/create_mo.sh merges the translation po files into one file and then creates the binary mo file from that.
Usage Scenarios
New Script
Developer adds a new script that contains translation. Once the script is finished, do the following from the lua-scripts directory:
Updated Script
Developer changes a script adding or removing translated strings. Once the script is finished, do the following from the lua-scripts directory:
Updated Translation File
Translator updates a po file with translations. Once the changes are done, do the following from the lua-scripts directory:
The tools run on Linux or MacOS only.
If a developer or translator doesn't want to or is unable to run the tools, then they can submit their PR and we'll take care of updating the translation stuff.
Summary of Changes
Most of the changes (28 languages x 39 scripts = 1,092) are the created translation files. All of the script files that use translation now point to "scripts" for their translation data. I preserved the old translation files. I also merged the script translations for the separate scripts that got merged into geoToolbox.lua.