Re: [Web-erp-developers] Translation

[skaill <sk...@ro...>]

Sounds great!

I can probably contribute a Danish translation in a few months.  French once
we get a demand for it since we will probably have to pay to get it done.
No, I'm not Danish but a partner is and we have connections there.

There are some very good translation programs out there that cover many
languages.  However, they don't do a perfect job so someone who knows the
language needs to look it over by comparing the English and translated
strings.  Hopefully those translation programs can handle a po file,
otherwise it would have to be converted to a format they handle and then
reassembled into a po.

May I suggest we each take on a few scripts at a time.  Once we're done them
then we can all do a few more, etc.  In this way someone will not be
modifying a huge number of scripts for an extended time and it's more
inspirational when each chunk gets completed quickly.  We could possibly do
by module or alphabet.

Might want to make a language field in the user, company and customer
tables.

Let me know which files I'm doing...

Steve

----- Original Message ----- 
From: "Phil Daintree" <p.d...@pa...>
To: <web...@li...>
Sent: Sunday, August 22, 2004 5:39 PM
Subject: [Web-erp-developers] Translation


> 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
>