Re: [Web-erp-developers] Translation

[Stins, D. <DR...@Zi...>]

All,

I definitely would like to have a translation to Dutch, but I do not know
yet in which year I have some time left to do this. After the translation of
Dutch is done, then I might be able to help with French too but I need then
some help of my friends and/or my wife.

First priority is to be sure that webERP meets all functional requirements
that we need in The Netherlands.

I think you are doing an excellent job with designing the architecture for
translations.

It might be an option to integrate the database solution with gettext
solution with .po files by entering the translations in the database and
create a report which creates the .po files. You can then create separate
column for the shortcut and generate the right string inclusive html to the
.po file. This opens also the possibility to replace the .po file by a
database interface. It's probably a better userfriendly interface for end
users to be able to alter translations in the database.

I would like to thank you all for the support and joining the project and
adding your contributions. Last year there was only Phil. I was looking for
accounting software and joined this project because the basic concepts (no
overhead, very clean, runs almost everywhere through basic php and mysql),
lots of functionality and last but not least: Phil's energy ant time to get
it all done.

Now there is interests from all over the world! :)

With best regards,

Dick Stins
----- Original Message -----
From: "Phil Daintree" <p.d...@pa...>
To: <web...@li...>
Sent: Sunday, August 22, 2004 11: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
>