language translation model

[youcantryreachingme]

Hi,

I notice that the current method for language translation is to assign the full text to a variable name. Example:

Code: [Select]

$ad_msg16 = "up to date.";
And then the code simply echoes the variable:

Code: [Select]

<?php echo $ad_msg14; ?>
This makes the code very unreadable.

If I'm looking to edit the code somewhere, I might find some text on the admin screen (for example "Create a new page") and search for it. I find the only match is in the translation file, which gives me the variable name and then I have to search for the variable name.

Apart from this taking 2 steps, when I do locate where the name is used, I get this:

Code: [Select]

<label><?php echo $ad_frm05; ?>?</label>
<?php echo $ad_msg14; ?>: <input type="radio" id="f_pr1" checked="checked" name="printable" value="Y" /> 
<?php echo $ad_msg15; ?>: <input type="radio" id="f_pr2" name="printable" value="N" />
<img src="img/icons/questionmark.gif" alt="Info" class="hints" title="<?php echo $ad_frm13; ?>" /><br/>
<label style="clear:both; margin-top: 6px;"><?php echo $ad_frm06; ?>?</label>
<?php echo $ad_msg14; ?>: <input type="radio"  id="f_pu1" checked="checked" name="published" value="Y" /> 
<?php echo $ad_msg15; ?>: <input type="radio" style="margin-top: 10px;" id="f_pu2" name="published" value="N" />
<img src="img/icons/questionmark.gif" alt="Info" class="hints" title="<?php echo $ad_frm14; ?>" /><br/>
<label style="clear:both; margin-top: 3px;"><?php echo $ad_frm20; ?>?</label>
<?php echo $ad_msg14; ?>: <input type="radio"  id="f_cod" name="iscoding" value="Y" /> 
<?php echo $ad_msg15; ?>: <input type="radio" style="margin-top: 10px;" id="f_co2" checked="checked" name="iscoding" value="N" />
Spend 3 seconds looking through the code and you've already forgotten which 'number' variable you were looking for - or if you're tracking a few different strings of text, which one is which?

As a suggestion, write a language translator class and use the english text as the index for the dictionary. This means the English text is in the main code. If the translator can't find a translation, then just output the text which is supplied in the code. This makes the code more readable (for English speakers - maybe you decide if another language is more appropriate or more of your developers use another language) and means when you search the entire codebase for a string you can go straight to the code that uses it rather than the 2 step process of looking up the translation file.

As an example, phpwebsite has translation files that look like this:

English example:

Code: [Select]

en:|:poll
a:|:Allow Comments:|:Allow Comments
a:|:Go here to create and edit your site's polls.:|:Go here to create and edit your site's polls.
a:|:Restricted:|:Restricted
First line defines the language and the module which uses the file. Each other line has delimiters and then the lookup value (1st) and translation (2nd).

Nl example:

Code: [Select]

nl:|:poll
a:|:Allow Comments:|:Sta commentaar toe
a:|:Restricted:|:Beperkt
and here is the call to the translator:

Code: [Select]

$_SESSION['translate']->it("Allow Comments");
And now you can directly see in the code what each text message is, without losing translation functionality.

Again - you have to choose your base language but at least a whole bunch of people using that language will find development easier.

One more benefit - when you're developing new code you don't worry about maintaining the translation file until the end. You just write the code, supply the English text to the translator (which spits it out unedited if it can't find it in the dictionary) and then when all development is done, search for all calls to the translator and write your dictionary.

[Xander]

Okay, I see what you're heading at. The one thing is that the use of classes and perhaps even an external (automatic) translator tool might slow things down. Since the main language is always already specified, you could perhaps easilier just rewrite the language files to be more readable. This could already be done by using more convenient variable naming (e.g. $lang['failed_database']). Or perhaps - to prevent later module development - $lang['core']['failed_database'].

Module developers should then include their own language file and use $lang['modx']['message']. Would that - do you think - do the trick?

I've had this on my list, since I already translated the config variables to be more universal in the 1.3.2 release. I'd also like to make an online translator tool that can automatically generate a lang file (which I then also have). Some users have already translated file, but never post back. I'd like to prevent that..

Let me know & your input is much appreciated!
Xander.

[Xander]

Whoops.. Locked this topic instead of the previous one. Suggestions are still welcome on my previous post. Currently I'm working to fix my not so neat way of coding causing huge pills of error logs to be created with all sorts of warnings. Will put this up on SVN later.