[Web-erp-developers] Translation

[Phil D. <p.d...@pa...>]

Rom, Luca and the team,

Luca, I hope you can forgive me in trying this gettext approach - I know
you were keen on the db method - which I relaise definitely has some
advantages.

I have started down the track of the gettext method of translating
webERP, it does seem to have a minimal impact on readability ... I
think? Take a look at the code and see what you think -comments
appreciated.


It is also very easy to modify the existing scripts. All strings are
just encapsulated in a call to the function _()

_("Some string")

there is a utility xgettext that extracts all the strings that are
encapsulated in this way to a .po file which is the core translation
file which has a msgid being the original text of the string and a
msgstr being the translation of that string into the alternative
language.In some strings there are bits of html mark up - which will
have to be retained where possible eg. on the links to Main Menu - the
string is 

"<u>M</u>ain Menu" indicating that the letter M is the shortcut using
CTRL+M (followed by enter in IE) is the same as clicking the link. This
may not be quite so useful in other languages.

If Rom could edit this file to make the appropriate translation for
Brazillian  Portugese that would enable me to prove the concept.

Luca may also like to have a go at the Italian. Has it been 2 weeks yet
- are you back Luca?

The only downer is that there are at least another 160 scripts to go!!

I am hoping there will be support from 

Rom (Brazillian/Portugese),
Luca (Italian),
Steve (French speaking Canadians?)
not sure if Dick is interested in a Dutch version,
not sure if Danie is interest in Africans (sp??)
and me

If we can divide the scripts up we could crack this quite quickly.
However, the translation on its own will be a significant project and
for that we can only rely on you clever bi-lingual folk.

It does seem particularly great to have all the strings extracted nicely
from the scripts using this xgettext function.

If the same string (exactly the same) occurs more than once in the .po
file you can delete the related msgid and msgstr of the subsequent
occurrences since they will not be needed.

I have attached the translation .po file as it stands (just for the
index.php, header.inc and session.inc) and a copy of index.php as
amended so you can see the minimal modifications required. The actual
additional translation code I have put in session.inc as this is
included in every script. The only other issue is that gettext must be
compiled in to PHP or the gettext.dll option in php.ini under windows is
uncommented. If gettext is not compiled in or the module activated then
the system defaults to the original english string.

One beauty of the approach is that the system cannot be broken this way
since even if gettext isnt installed I have a default function that just
returns the english string. This is one aspect that I really like
because if I am left holding the baby - at least the system isn't
trashed and I can just mark the whole multi-language thing off to
experience.

Men, with your support I think this will work!

I think this is the minimal hassle route to multi-language webERP.

If the concept proves ok then all that needs to be done is:

1. split up the scripts between us 
2. encapsulate every string in _("????") 
3. send them back to me
4. I create one large .po file
5. Send back to the translation team Rom, Luca, Dick? for translation
6. Send me back the translated .po files
7. I create the binary .pot files using the gettext utilities

et voila! (the extent of my French!) Brazillian/Portugese, Italian,
Dutch?, Africans? webERP!

We could easily make an additional field for language in the user table
to allow the users to all have different languages.

In terms of ongoing maintenance the xgettext utlity allows only new
strings not already in the main messages.po file to be extracted too so
all the leg work is removed - each time a script is changed the small
additional .po file is circulated to the translators and fired back into
the main messages.po file for creating the new .pot binary.

All thoughts and comments always appreciated.

Phil