Facilitating translations - Just an idea
Split the text strings from the actual scripts
Bernard,
Wouldn't it be possible to place the typical language dependent strings in a separate library file that can then be consoluted by the scripts when on screen strings are needed? In this way it would be much simpler to make a translation. You would only have to take the original English or French library and start translating. The only thing to add in the script then is the selected language and even that could be done dynamically by looking at which libraries exist in the library directory.
e.g. local_language_FR.dict local_language_DE.dict local_language_EN.dict local_language_NL.dict ...
At the same time you would also save time as one string reappears in multiple files.
Cheers
Jan
Wouldn't it be possible to place the typical language dependent strings in a separate library file that can then be consoluted by the scripts when on screen strings are needed? In this way it would be much simpler to make a translation. You would only have to take the original English or French library and start translating. The only thing to add in the script then is the selected language and even that could be done dynamically by looking at which libraries exist in the library directory.
e.g. local_language_FR.dict local_language_DE.dict local_language_EN.dict local_language_NL.dict ...
At the same time you would also save time as one string reappears in multiple files.
Cheers
Jan
Bernard from nearby-an-airport Associate, 6674 posts |
Jan: Actually, what you are suggesting is what is commonly proposed for software translation. A number of programs I worked on previously were structured this way. For YACS, I have deliberately selected to depart from this scheme, because of the very high number of changes provided with each release. A single language file is handy for the translation itself, but it adds on developer burden, because the centralisation of every string is really a tedious overhead. Therefore, this makes sense when the set of features is quite stable. But this is not the case of YACS, which adds a bunch of new features on every release. At the moment localization is achieved within each script, since this is the most straightforward approach for any PHP developer. Note, however, that this could evolve later on to a centralized file for all strings, as soon someone will dedicate some time on this. |
| Vinc from Bruxelles 114 posts |
Where could I Put the file containing all the occurences of English text? |
| Bernard from nearby-an-airport Associate, 6674 posts |
Thanks to Vinc, we now have a central place to help translators. Visit English strings in YACS to fetch a single file of all strings used in YACS. |
| Puran 4 posts |
Bernard: Isn't it true that, with a growing number of translations, the memory use grow too? As all the text from each language must be loaded into memory it could influence the time used to load also. It's a long time ago I practice programming but maybe I have an idea that could be of help (or give you a good laugh  ).While writing code work with a version that has one line with an extra code. For example you have in the index.php the lines: $local['label_en'] = 'Collections'; $local['label_fr'] = 'Collections'; Change that to: // $lang $local['label_(lang of your choice)'] = 'Collections'; $local['label'] = get_local(label['lang']'); (not sure how to put the var's) with the use of var's in stead of several lines of text. So you start using one local var in stead of several textlines, but at writing time they are visable saving you that bunch of a overhead you write about. Before compiling/debug to test the bunch use a script to get every first line after "// $lang" and copy it to a lang file, compare it with the former file and save the added/changed lines for publishing to translators. Make a backup for the next version en run a script that remove the // $lang and first folowing line from youre sourcecode before compiling and testing and publishing the script(s). Maybe it helps, greetings Karel. |
| Bernard from nearby-an-airport Associate, 6674 posts |
Puran: What you are describing here is quite close of what we have in mind for next versions of YACS. Ultimately, YACS scripts will only reference strings, and these will be centralised in one file per language. Thank you for the tip, and fo ryou rinterest in YACS. |
Rate this page
Posted by JBN on Dec. 3 2005, commented by Bernard on Dec. 3 2005, (popular)
