Good point, but let's approach that with some tact.
Nathan
Discussion: translating Puppys System-tools
Some thoughts
I just want to propose an approach to simplify Puppy scripts and wizards internationalization.
There is an approach without MU's 1'st step (Replace each word with a variable): every localizable piece of text is left in place in english but passed as a peremeter to translating function t(). t() is trivial when locale (or other variable) set to english, and returns appropriate translation in other case.
Similar thing is used in Drupal CMS for localization. Actual translated pieces of code are stored in database (we can use SQLLite) and exported/imported using .po files. We can replace database with a gettext library to work with po and mo without database.
The advantage of this approach is tiny the ammount of effort from developers of scripts and wizards -- no need to insert constants, just add t() function calls. English po files for translations are created automatically from script/wizard by a perl or php script (we can use Drupal's extract.php).
The disadvantage is speed and duplication (we can't throw out english from localized version, it wasetes space cause it is built into sources).
There is an approach without MU's 1'st step (Replace each word with a variable): every localizable piece of text is left in place in english but passed as a peremeter to translating function t(). t() is trivial when locale (or other variable) set to english, and returns appropriate translation in other case.
Similar thing is used in Drupal CMS for localization. Actual translated pieces of code are stored in database (we can use SQLLite) and exported/imported using .po files. We can replace database with a gettext library to work with po and mo without database.
The advantage of this approach is tiny the ammount of effort from developers of scripts and wizards -- no need to insert constants, just add t() function calls. English po files for translations are created automatically from script/wizard by a perl or php script (we can use Drupal's extract.php).
The disadvantage is speed and duplication (we can't throw out english from localized version, it wasetes space cause it is built into sources).
GuestToo alredy tested proposed approach, I just found his gettext translating program - demo 2 topic. Just "eval_gettext" instead of "t".
Localization
I would like to get back to Kingskid's remark on getting the translations done. If the developers can settle on the approach (ie gettext, or?) and provide the necessary translation file & format some of us lesser mortals could do translations.
And I'll put the stake in the ground right now -- I'll sign my family up for the Russian translation.
And I'll put the stake in the ground right now -- I'll sign my family up for the Russian translation.
my dotpup handler script in Puppy 210 and 211 uses gettext for translation ... there are only 2 translations so far, de and fr
the trouble is, i used xmessage/gxmessage to display the messages ... xmessage is small and simple ... xmessage is a gtk1 app, so it does not display unicode properly ... gxmessage is a gtk2 app, and can display unicode characters
so i have to think about what to do ... gxmessage is small, 21k (11k if compressed with UPX), but it is not included in the standard Puppy iso
i could rewrite the handler script so that it uses another program to display messages that will support UFT8
or i could make sure gxmessage is installed when translations are installed, and if gxmessage is not available to force en messages
the handler script is really just the first alpha version of an experiment using gettext, but since the older script supposedly did not work in Puppy 210, the experimental alpha script was put in Puppy 210 ... it seems to work ok, so far, but translations are not fully supported, because of xmessage
i guess it could be rewritten using gtkdialog ... xmessage has a simpler syntax, though ... i like to keep things simple ... maybe a puppybasic wrapper would keep it the script simple ...
oh, and the script has changed since the .po file was made ... the strings are still the same, just the line numbers are a little different
the trouble is, i used xmessage/gxmessage to display the messages ... xmessage is small and simple ... xmessage is a gtk1 app, so it does not display unicode properly ... gxmessage is a gtk2 app, and can display unicode characters
so i have to think about what to do ... gxmessage is small, 21k (11k if compressed with UPX), but it is not included in the standard Puppy iso
i could rewrite the handler script so that it uses another program to display messages that will support UFT8
or i could make sure gxmessage is installed when translations are installed, and if gxmessage is not available to force en messages
the handler script is really just the first alpha version of an experiment using gettext, but since the older script supposedly did not work in Puppy 210, the experimental alpha script was put in Puppy 210 ... it seems to work ok, so far, but translations are not fully supported, because of xmessage
i guess it could be rewritten using gtkdialog ... xmessage has a simpler syntax, though ... i like to keep things simple ... maybe a puppybasic wrapper would keep it the script simple ...
oh, and the script has changed since the .po file was made ... the strings are still the same, just the line numbers are a little different