Translation

[a.tangemann@…]

Hello,

this a demonstration patch how to implement translation. I have translated the name and password field on the login page. You have to switch your internet browser to German to see the translated page. Patch and screenshot included.

best regards Andreas Tangemann

[brieb]

This looks great! What I'd like to do is wait about a week until we get some of the glaring v0.98 bugs sorted out and the api/apiwrapper solidified a little more, and then create a branch of the trunk to put this patch into and really flush it out.

Love the idea of reverting to trying a CSV file if it can't connect to a DB for the install.

Some other things to think about:

1. What if we pre-load the translations into an associative array (do something similar on the JS side) to speed things up? The keys would consist of an md5 hash of the source.
   
   sample
   $tranlations['t'.md5($therecord["source"])] = $therecord["destination"];
   
   Then the translator would need to do a lookup on the md5 of the source for it's destination.
   
   
2. To limit the size of these loaded arrays, what if we add a field to the translation field called "context". By default, items with context "base" will always be loaded, but then each file could also load other contexts as well, such as "OrderEntry?", or "BMSModule".
   
   
3. Rather than relying on the browser for locale, why not make it a user setting, set in "My Account", with a default setting in the configuration page?
   
   
4. To aid in creating translations, we do the following:
   • Add a "Create Translation" setting you can turn on or off. With this turned on, If the translation cannot be found, it will create an entry in the database.
   • Add a "translated" boolean field to the translation table, so you can mark when the translation has been done.
   • Add a "possibleContexts" field containing a comma separated lists of all context loaded on the page. to the translation table, so people translating can at least guess which context the translation belongs.
   • Add a tabledef and add/edit screen for translations.

[a.tangemann@…]

Let us begin with number 3: The advantage of using the browser setup for languages is that the user can define many languages. So for example you can define first priority German, second priority Dutch and third priority French. A disadvantage of using a parameter in the user data is that you need to deal with all possible languages. Either you have to list them in the settings dialog or in a separate table. Do you still think a parameter is the best solution?

[brieb]

Can't you get a list of installed languages by just doing a

SELECT DISTINCT locale FROM translations ORDER BY locale

Actually, I think doing parameter or browser locale both have advantages and disadvantages. I am open to either, but probably need more knowledge of how browser locales work:

1) How do you change your locale - on let's say Firefox?

2) Do different browsers/versions handle locales differently?

Assuming I can wrap my head around it.... I think browser locale has more advantages then a user setting.

[a.tangemann@…]

1) How do you change your locale - on let's say Firefox?

Go to the "Tools" menu and choose "Options". Select the "Content" tab and click on "Choose" at the bottom in the languages area. There you add languages and move them up and down.

2) Do different browsers/versions handle locales differently?

The actual Internet Explorer version handle locales the same way. I do not know about older versions or other browsers.

Do you agree to continue with the browser locale?

[brieb]

I agree. Browser Locale is a fine solution.

[brieb]

Any thoughts on the other points?

[a.tangemann@…]

I would like to continue with point 4. I understand the sentence, so I am creating a add/edit page and so on. But I do not understand the other sentences. Maybe you can explain a little bit more what you mean.

[brieb]

To the first point of number 4. I had noticed that in our sample code, when it could not find a translation, it logged it to a file. I think this is done so you can then find out what needs to be translated.

I recommend putting in a setting, that when turned on would act the same way, except instead of logging it to a file, would add an entry to the database and mark it as "needs translating" so that someone could easily find what needs to be translated

Now this logging would only happen if the setting was turned on (for speed purposes)

To the second and third points of number 4: When you have this setting turned on, and the system is logging entries into the DB that need translating, adding a field that would identify it as needing translation could help people see what needs to be translated and what doesn't.

If you have loaded translations form multiple contexts on a page (See number 2) The possible contexts field would contain a comma separated list of all the loaded contexts on a page. This would aid the person doing the translation in determining which context the item needs to be categorized in.

Hope that helps.

[a.tangemann@…]

I have a problem implementing the setting to log untranslated translations. I have setup a new tab in the configuration file (see new attachement). The tab and the setting are showing, but when I change and save the setting, it is not getting saved. The $_POST variable does not contain my new setting. Any ideas?

[brieb]

I get the following error when trying to install:

Fatal error: Class 'SQLite3' not found in /phpbms/include/translation.php on line 112

[a.tangemann@…]

I am sorry, but I have used SQLite instead of csv for translation the installation pages.
You can either install the SQLite extension or comment lines 112-122 in file /phpbms/include/translation.php.

[brieb]

I am working on the code now based on our patch.

It was not outputting anything when I set my locale to en-US. I will upload a patch to check out soon.

[a.tangemann@…]

I have attached a new patch:
The installation process takes the translations from a SQLite3 database, that can be exported from the normal application.
The normal application takes the translations from the mysql database.
A parameter in the base module has been created to log untranslated messages.
If the parameter has been set, untranslated messages will be logged in the table. A special flag will be set, so that this message has to be translated.
A menu item in the system menu has been created to maintain the translations.

[a.tangemann@…]

Any news here?