Menu
▾
▴
web-erp-developers
|
From: Phil D. <p.d...@pa...> - 2004-08-22 09:38:06
|
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
|
|
From: Phil D. <we...@pa...> - 2004-09-02 10:28:26
|
Gentlemen,
I have been having a play with gettext and have it working - it needs to
be enabled on your server.... if its not the system will product only
english. The CVS has a couple of strings in the italian messages.po for
the purposes I certainly would not vouch for the accuracy of the
translations !! However, clearly shows that it is going to work
brilliantly.... IF WE have the determination and staying power to
convert every string assigment/print statement and echo statement in the
whole system.
Frankly, I am seriously daunted by the propsect and will not be able to
do it on my own.
A few points about the conversion ...
Page $title = _('Page Title'); should also be encapsulated in the get
text function.
Single quotes ' are faster than double quotes " - PHP has to parse the
contents of double quotes for variable substitutions but doesn't for
single quotes. Strings that have variables in the middle and spaces or
html tags need to be broken up ideally eg.
echo "<P>A long string full of $NumberOfCharacters characters";
would need to be re-written as:
echo '<P>' . _('A long string full of') . ' ' . $NumberOfCharacters . '
' . _('characters');
I think it would be better to avoid having html or trailing spaces in
the translation strings.
Jessie Peterson made a modification to the DB_query function such that
the repetitive use of
if (DB_error_no($db) !=0) { .....
is no longer necessary - all you need to do is send DB_query the error
message as the 3rd parameter, the 4th parameter is the Debug message and
the 5th is whether the query is inside a transaction that should
rollback. This might be a good opportunity to tidy up calls to DB_query
to use these extra parameters too? This would take quite a bit of code
out of the scripts.
Some submit buttons have their value checked - clearly the value of a
submit button - what is displayed on the face of it - will need to be
inside a gettext function call - so too must the comparison string eg.
say a submit button named 'Search' is tested to see if it is hit - the
value of the button will need to be changed to the local language -
assuming the button is to have a local language label....
if ($_POST['Search'] == _('Search Now')){
Steve's approach to "eating the elephant" seemed good - lets break it
down to bite sized chunks ....
I'll kick off with:
AccountGroups.php
AgedDebtors.php
AgedSuppliers.php
Areas.php
BOMInquiry.php
BOMListing.php
Steve - would you have a go at:
BOMs.php
BankAccounts.php
BankMatching.php
BankReconciliation.php
COGSGLPostings.php
CompanyPreferences.php
Luca - would you have a go at:
ConfirmDispatchControlled_Invoice.php
ConfirmDispatch_Invoice.php
CreditItemsControlled.php
CreditStatus.php
Credit_Invoice.php
Currencies.php
Rom - would you have a go at:
CustEDISetup.php
CustWhereAlloc.php
CustomerBranches.php
CustomerInquiry.php
CustomerReceipt.php
CustomerTransInquiry.php
The major worry here is introducing new bugs so please test the scripts
individually and thoroughly before emailing me with them.
Any other offers to help would be fantastic.
Let me know if there are any other ideas or areas of ambiguity.
If you need to see how to convert a script look at index.php or
UserSettings.php
Phil
|
|
From: skaill <sk...@ro...> - 2004-09-02 11:21:49
|
Sure, I think I can do those pages but I can only superficially test them as
I'm honestly not that familiar with those areas and may not know if I've
introduced an error. Unfortunately you may need to do some extended testing
if you want to have good confidence in all the translation code changes.
After we do each section we should get someone who is using webERP and wants
translation to use it for a week or two to make sure there are no errors
with what we've done. After that, proceed to the next set.
The types of changes we are making theoretically should not get us into much
trouble though.
Although the value gets changed in the Submit (and other inputs) the name
should remain the same to keep the code all in one language (English).
One tricky circumstance is if 'Y' and 'N' have been used for boolean.
These values get stored as data. The data cannot be translated from Y or N
as stored or the logic test of if TestFlag == "Y" wouldn't work when you
changed languages. It would work if you changed the right half but only for
one language! The best solution is to translate when displayed.
It all has to do with display time as opposed to code logic.
Steve
----- Original Message -----
From: "Phil Daintree" <we...@pa...>
To: <web...@li...>
Sent: Thursday, September 02, 2004 6:28 AM
Subject: [Web-erp-developers] Translation
> Gentlemen,
>
> I have been having a play with gettext and have it working - it needs to
> be enabled on your server.... if its not the system will product only
> english. The CVS has a couple of strings in the italian messages.po for
> the purposes I certainly would not vouch for the accuracy of the
> translations !! However, clearly shows that it is going to work
> brilliantly.... IF WE have the determination and staying power to
> convert every string assigment/print statement and echo statement in the
> whole system.
>
> Frankly, I am seriously daunted by the propsect and will not be able to
> do it on my own.
>
> A few points about the conversion ...
>
> Page $title = _('Page Title'); should also be encapsulated in the get
> text function.
>
> Single quotes ' are faster than double quotes " - PHP has to parse the
> contents of double quotes for variable substitutions but doesn't for
> single quotes. Strings that have variables in the middle and spaces or
> html tags need to be broken up ideally eg.
>
> echo "<P>A long string full of $NumberOfCharacters characters";
>
> would need to be re-written as:
>
> echo '<P>' . _('A long string full of') . ' ' . $NumberOfCharacters . '
> ' . _('characters');
>
> I think it would be better to avoid having html or trailing spaces in
> the translation strings.
>
> Jessie Peterson made a modification to the DB_query function such that
> the repetitive use of
>
> if (DB_error_no($db) !=0) { .....
>
> is no longer necessary - all you need to do is send DB_query the error
> message as the 3rd parameter, the 4th parameter is the Debug message and
> the 5th is whether the query is inside a transaction that should
> rollback. This might be a good opportunity to tidy up calls to DB_query
> to use these extra parameters too? This would take quite a bit of code
> out of the scripts.
>
> Some submit buttons have their value checked - clearly the value of a
> submit button - what is displayed on the face of it - will need to be
> inside a gettext function call - so too must the comparison string eg.
>
> say a submit button named 'Search' is tested to see if it is hit - the
> value of the button will need to be changed to the local language -
> assuming the button is to have a local language label....
>
> if ($_POST['Search'] == _('Search Now')){
>
> Steve's approach to "eating the elephant" seemed good - lets break it
> down to bite sized chunks ....
>
> I'll kick off with:
>
> AccountGroups.php
> AgedDebtors.php
> AgedSuppliers.php
> Areas.php
> BOMInquiry.php
> BOMListing.php
>
> Steve - would you have a go at:
>
> BOMs.php
> BankAccounts.php
> BankMatching.php
> BankReconciliation.php
> COGSGLPostings.php
> CompanyPreferences.php
>
> Luca - would you have a go at:
>
> ConfirmDispatchControlled_Invoice.php
> ConfirmDispatch_Invoice.php
> CreditItemsControlled.php
> CreditStatus.php
> Credit_Invoice.php
> Currencies.php
>
> Rom - would you have a go at:
>
> CustEDISetup.php
> CustWhereAlloc.php
> CustomerBranches.php
> CustomerInquiry.php
> CustomerReceipt.php
> CustomerTransInquiry.php
>
>
> The major worry here is introducing new bugs so please test the scripts
> individually and thoroughly before emailing me with them.
>
> Any other offers to help would be fantastic.
>
> Let me know if there are any other ideas or areas of ambiguity.
>
> If you need to see how to convert a script look at index.php or
> UserSettings.php
>
> Phil
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
|
|
From: Phil D. <we...@pa...> - 2004-09-03 10:56:39
|
This is quite a serious concern with this project. It would be most upsetting to introduce more problems than we resolve - I am very keen to keep the code stable. I am fairly confident (I think) that these changes will cause parsing errors if there is a mistake in the code ie missed out a . or closing ' or something so I am thinking that the page will be ok or it wont actually run. If it runs then there is a good chance that no logic errors will be introduced. The only area of concern is the use of submit buttons where I have tested for a returned value. In most cases these can be changed to isset. Phil On Thu, 2004-09-02 at 23:22, skaill wrote: > Sure, I think I can do those pages but I can only superficially test them as > I'm honestly not that familiar with those areas and may not know if I've > introduced an error. Unfortunately you may need to do some extended testing > if you want to have good confidence in all the translation code changes. > > After we do each section we should get someone who is using webERP and wants > translation to use it for a week or two to make sure there are no errors > with what we've done. After that, proceed to the next set. > > The types of changes we are making theoretically should not get us into much > trouble though. > > Although the value gets changed in the Submit (and other inputs) the name > should remain the same to keep the code all in one language (English). > > One tricky circumstance is if 'Y' and 'N' have been used for boolean. > These values get stored as data. The data cannot be translated from Y or N > as stored or the logic test of if TestFlag == "Y" wouldn't work when you > changed languages. It would work if you changed the right half but only for > one language! The best solution is to translate when displayed. > > It all has to do with display time as opposed to code logic. > > Steve |
|
From: skaill <sk...@ro...> - 2004-09-03 12:01:03
|
I would agree. It is a fairly simple conversion and would introduxe an error as opposed to screwing up the logic. We are only putting in . and ' and _ ( ). The only added concern is the possible booleans which will be fine if everyone understands to translate them only when displayed. The booleans will be obvious because they will all have a 'Y' or 'N' hard coded in an if statement. That's what they're meant for. If you see a 'Y' or 'N' then if you are not sure then DON'T change them. Steve ----- Original Message ----- From: "Phil Daintree" <we...@pa...> To: <web...@li...> Sent: Friday, September 03, 2004 6:57 AM Subject: Re: [Web-erp-developers] Translation > This is quite a serious concern with this project. It would be most > upsetting to introduce more problems than we resolve - I am very keen to > keep the code stable. I am fairly confident (I think) that these changes > will cause parsing errors if there is a mistake in the code ie missed > out a . or closing ' or something so I am thinking that the page will be > ok or it wont actually run. If it runs then there is a good chance that > no logic errors will be introduced. The only area of concern is the use > of submit buttons where I have tested for a returned value. In most > cases these can be changed to isset. > > Phil > > On Thu, 2004-09-02 at 23:22, skaill wrote: > > Sure, I think I can do those pages but I can only superficially test them as > > I'm honestly not that familiar with those areas and may not know if I've > > introduced an error. Unfortunately you may need to do some extended testing > > if you want to have good confidence in all the translation code changes. > > > > After we do each section we should get someone who is using webERP and wants > > translation to use it for a week or two to make sure there are no errors > > with what we've done. After that, proceed to the next set. > > > > The types of changes we are making theoretically should not get us into much > > trouble though. > > > > Although the value gets changed in the Submit (and other inputs) the name > > should remain the same to keep the code all in one language (English). > > > > One tricky circumstance is if 'Y' and 'N' have been used for boolean. > > These values get stored as data. The data cannot be translated from Y or N > > as stored or the logic test of if TestFlag == "Y" wouldn't work when you > > changed languages. It would work if you changed the right half but only for > > one language! The best solution is to translate when displayed. > > > > It all has to do with display time as opposed to code logic. > > > > Steve > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: skaill <sk...@ro...> - 2004-09-20 21:39:54
|
Here's another, Jake...it's about only translating boolean when displayed, not when set or tested... ----- Original Message ----- From: "skaill" <sk...@ro...> To: <web...@li...> Sent: Friday, September 03, 2004 8:01 AM Subject: Re: [Web-erp-developers] Translation > I would agree. It is a fairly simple conversion and would introduxe an > error as opposed to screwing up the logic. We are only putting in . and ' > and _ ( ). The only added concern is the possible booleans which will be > fine if everyone understands to translate them only when displayed. The > booleans will be obvious because they will all have a 'Y' or 'N' hard coded > in an if statement. That's what they're meant for. > > If you see a 'Y' or 'N' then if you are not sure then DON'T change them. > > Steve > > ----- Original Message ----- > From: "Phil Daintree" <we...@pa...> > To: <web...@li...> > Sent: Friday, September 03, 2004 6:57 AM > Subject: Re: [Web-erp-developers] Translation > > > > This is quite a serious concern with this project. It would be most > > upsetting to introduce more problems than we resolve - I am very keen to > > keep the code stable. I am fairly confident (I think) that these changes > > will cause parsing errors if there is a mistake in the code ie missed > > out a . or closing ' or something so I am thinking that the page will be > > ok or it wont actually run. If it runs then there is a good chance that > > no logic errors will be introduced. The only area of concern is the use > > of submit buttons where I have tested for a returned value. In most > > cases these can be changed to isset. > > > > Phil > > > > On Thu, 2004-09-02 at 23:22, skaill wrote: > > > Sure, I think I can do those pages but I can only superficially test > them as > > > I'm honestly not that familiar with those areas and may not know if I've > > > introduced an error. Unfortunately you may need to do some extended > testing > > > if you want to have good confidence in all the translation code changes. > > > > > > After we do each section we should get someone who is using webERP and > wants > > > translation to use it for a week or two to make sure there are no errors > > > with what we've done. After that, proceed to the next set. > > > > > > The types of changes we are making theoretically should not get us into > much > > > trouble though. > > > > > > Although the value gets changed in the Submit (and other inputs) the > name > > > should remain the same to keep the code all in one language (English). > > > > > > One tricky circumstance is if 'Y' and 'N' have been used for boolean. > > > These values get stored as data. The data cannot be translated from Y > or N > > > as stored or the logic test of if TestFlag == "Y" wouldn't work when you > > > changed languages. It would work if you changed the right half but only > for > > > one language! The best solution is to translate when displayed. > > > > > > It all has to do with display time as opposed to code logic. > > > > > > Steve > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by BEA Weblogic Workshop > > FREE Java Enterprise J2EE developer tools! > > Get your free copy of BEA WebLogic Workshop 8.1 today. > > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > > _______________________________________________ > > Web-erp-developers mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: skaill <sk...@ro...> - 2004-09-20 21:49:13
|
Here is another about what to do with submits. Basically translate the
value and not the name. Also we have been eliminating the testing of a
certain value in the submit and just seeing if it is set instead. This
works as long as there is only one value possible for the submit and
everywhere I have seen so far that is the case.
Steve
----- Original Message -----
From: "skaill" <sk...@ro...>
To: <web...@li...>
Sent: Thursday, September 02, 2004 7:22 AM
Subject: Re: [Web-erp-developers] Translation
> Sure, I think I can do those pages but I can only superficially test them
as
> I'm honestly not that familiar with those areas and may not know if I've
> introduced an error. Unfortunately you may need to do some extended
testing
> if you want to have good confidence in all the translation code changes.
>
> After we do each section we should get someone who is using webERP and
wants
> translation to use it for a week or two to make sure there are no errors
> with what we've done. After that, proceed to the next set.
>
> The types of changes we are making theoretically should not get us into
much
> trouble though.
>
> Although the value gets changed in the Submit (and other inputs) the name
> should remain the same to keep the code all in one language (English).
>
> One tricky circumstance is if 'Y' and 'N' have been used for boolean.
> These values get stored as data. The data cannot be translated from Y or
N
> as stored or the logic test of if TestFlag == "Y" wouldn't work when you
> changed languages. It would work if you changed the right half but only
for
> one language! The best solution is to translate when displayed.
>
> It all has to do with display time as opposed to code logic.
>
> Steve
>
>
> ----- Original Message -----
> From: "Phil Daintree" <we...@pa...>
> To: <web...@li...>
> Sent: Thursday, September 02, 2004 6:28 AM
> Subject: [Web-erp-developers] Translation
>
>
> > Gentlemen,
> >
> > I have been having a play with gettext and have it working - it needs to
> > be enabled on your server.... if its not the system will product only
> > english. The CVS has a couple of strings in the italian messages.po for
> > the purposes I certainly would not vouch for the accuracy of the
> > translations !! However, clearly shows that it is going to work
> > brilliantly.... IF WE have the determination and staying power to
> > convert every string assigment/print statement and echo statement in the
> > whole system.
> >
> > Frankly, I am seriously daunted by the propsect and will not be able to
> > do it on my own.
> >
> > A few points about the conversion ...
> >
> > Page $title = _('Page Title'); should also be encapsulated in the get
> > text function.
> >
> > Single quotes ' are faster than double quotes " - PHP has to parse the
> > contents of double quotes for variable substitutions but doesn't for
> > single quotes. Strings that have variables in the middle and spaces or
> > html tags need to be broken up ideally eg.
> >
> > echo "<P>A long string full of $NumberOfCharacters characters";
> >
> > would need to be re-written as:
> >
> > echo '<P>' . _('A long string full of') . ' ' . $NumberOfCharacters . '
> > ' . _('characters');
> >
> > I think it would be better to avoid having html or trailing spaces in
> > the translation strings.
> >
> > Jessie Peterson made a modification to the DB_query function such that
> > the repetitive use of
> >
> > if (DB_error_no($db) !=0) { .....
> >
> > is no longer necessary - all you need to do is send DB_query the error
> > message as the 3rd parameter, the 4th parameter is the Debug message and
> > the 5th is whether the query is inside a transaction that should
> > rollback. This might be a good opportunity to tidy up calls to DB_query
> > to use these extra parameters too? This would take quite a bit of code
> > out of the scripts.
> >
> > Some submit buttons have their value checked - clearly the value of a
> > submit button - what is displayed on the face of it - will need to be
> > inside a gettext function call - so too must the comparison string eg.
> >
> > say a submit button named 'Search' is tested to see if it is hit - the
> > value of the button will need to be changed to the local language -
> > assuming the button is to have a local language label....
> >
> > if ($_POST['Search'] == _('Search Now')){
> >
> > Steve's approach to "eating the elephant" seemed good - lets break it
> > down to bite sized chunks ....
> >
> > I'll kick off with:
> >
> > AccountGroups.php
> > AgedDebtors.php
> > AgedSuppliers.php
> > Areas.php
> > BOMInquiry.php
> > BOMListing.php
> >
> > Steve - would you have a go at:
> >
> > BOMs.php
> > BankAccounts.php
> > BankMatching.php
> > BankReconciliation.php
> > COGSGLPostings.php
> > CompanyPreferences.php
> >
> > Luca - would you have a go at:
> >
> > ConfirmDispatchControlled_Invoice.php
> > ConfirmDispatch_Invoice.php
> > CreditItemsControlled.php
> > CreditStatus.php
> > Credit_Invoice.php
> > Currencies.php
> >
> > Rom - would you have a go at:
> >
> > CustEDISetup.php
> > CustWhereAlloc.php
> > CustomerBranches.php
> > CustomerInquiry.php
> > CustomerReceipt.php
> > CustomerTransInquiry.php
> >
> >
> > The major worry here is introducing new bugs so please test the scripts
> > individually and thoroughly before emailing me with them.
> >
> > Any other offers to help would be fantastic.
> >
> > Let me know if there are any other ideas or areas of ambiguity.
> >
> > If you need to see how to convert a script look at index.php or
> > UserSettings.php
> >
> > Phil
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by BEA Weblogic Workshop
> > FREE Java Enterprise J2EE developer tools!
> > Get your free copy of BEA WebLogic Workshop 8.1 today.
> > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
|
|
From: skaill <sk...@ro...> - 2004-08-22 11:35:33
|
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
>
|
|
From: Hani N. <ha...@na...> - 2004-08-22 13:31:31
|
Hi Phil, One note, you don't really need gettext to be compiled with php (if it is great then use it because of the speed improvements) but if not there are simple php based gettext implementations. I thought someone had already posted a function that checked for that and acted accordingly. Although gettext is pre-compiled at most ISPs it does not come with the default php installers which is probably what people will be using when they first download weberp for evaluation. Hani |
|
From: skaill <sk...@ro...> - 2004-08-22 13:39:47
|
I think InfoCentral (in SourceForge) checks whether gettext is installed and deals with it accordingly. Steve ----- Original Message ----- From: "Hani Naguib" <ha...@na...> To: <web...@li...> Sent: Sunday, August 22, 2004 9:31 AM Subject: Re: [Web-erp-developers] Translation > Hi Phil, > One note, you don't really need gettext to be compiled with php (if it > is great then use it because of the speed improvements) but if not there > are simple php based gettext implementations. > I thought someone had already posted a function that checked for that > and acted accordingly. > Although gettext is pre-compiled at most ISPs it does not come with the > default php installers which is probably what people will be using when > they first download weberp for evaluation. > > Hani > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Stins, D. <DR...@Zi...> - 2004-08-22 14:34:42
|
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
>
|
|
From: Phil D. <p.d...@pa...> - 2004-08-23 07:30:27
|
Thanks Hani, at the mo I have a dummy gettext function that just returns the English string so it deals with a no gettext install by not being a multi-language system. This is a little blunt perhaps! I just updated to PHP 5 and understand that gettext doesn't actually work with the windows version at least. I will have to take out my dummy function to check!! Phil On Mon, 2004-08-23 at 01:31, Hani Naguib wrote: > Hi Phil, > One note, you don't really need gettext to be compiled with php (if it > is great then use it because of the speed improvements) but if not there > are simple php based gettext implementations. > I thought someone had already posted a function that checked for that > and acted accordingly. > Although gettext is pre-compiled at most ISPs it does not come with the > default php installers which is probably what people will be using when > they first download weberp for evaluation. > > Hani |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X