Menu
▾
▴
web-erp-developers
|
From: ing. L. Tur <luc...@pd...> - 2004-09-06 14:35:48
|
Hello Phil,
sorry for my silence, but I had some troubles that kept me away from work.
I've seen that you started to work on the gettext solution.
I've spent some time last week to study the approach of gettext, and my
opinion is that we the gettext solution is efficient but has the problem that
the translations can be done without any control, i.e. you simply change a
text file.
Given thsi I have started thinking how I could get the best from the gettext
approach and still keeping the db repository for the languages.
I made some experiment and sorted out the following.
In my "language.php" file I've defined a function translate(), which receives
a parameter which can be a string or an identifier. The function uses the
$lang array, which contains all the translations needed, and which is loaded
at the beginning.
function translate($idOfLabelToBeTranslated)
{
global $lang;
if ($lang[$idOfLabelToBeTranslated]!=null)
return $lang[$idOfLabelToBeTranslated];
else
return $idOfLabelToBeTranslated;
}
As you can see translate simply returns the translated message, which has then
to be echoed (so it is very similar to gettext_noop...)
I also enlarged the db column containing the label identifier: now it's 100
chars and can be enlarged again.
Since $idOfLabelToBeTranslated can be a string you can maintain code
readability, as you can see in the following chunk of code from
SelectCustomer.php
....
if ($_POST['Search']==translate("Search Now")){
If ($_POST['Keywords'] AND $_POST['CustCode']) {
$msg= translate("Customer name keywords have been used in
preference to the customer code extract entered.");
$_POST["Keywords"] = strtoupper($_POST["Keywords"]);
}
If ($_POST['Keywords']=="" AND $_POST['CustCode']=="") {
$msg=translate("At least one customer name keyword OR an
extract of a customer code must be entered for the search");
.....
As you can understand, using this approach I am addressing your main concern,
which is maintaining the code easy to read.
But also I am addressing my 2 concerns: having the application working at any
time, even during translation, and having a simple way to translate without
the danger of destroying the application. These issues are very important to
me; since I believe that a translator have to be free to see exactly where a
certain sentence appears, in order to deeply understand the meaning and give a
proper translation. A translation with the gettext approach is done without
simultaneously looking at the application. Using my approach you can have one
browser on the application and the other one in the application created for
translation (i.e. some php pages that show the original and let you write the
translation in a form)
Now I am trying to solve the problem of parameters within a sentence, and in
particular the fact that the position of parameters can change from one
language to another (see the english-german example in the gettext
documentation)..
Finally: Phil, if you don't like this approach, i am going to bend down and
conform to you decision. The use of "translate" function is exactly as
gettext_noop, so it'll be easy to adapt. But please first try to consider the
db solution.
Luca
|
|
From: Jesse P. <je...@st...> - 2004-09-06 16:23:34
|
Luca Turlon Donà wrote: >I've spent some time last week to study the approach of gettext, and my >opinion is that we the gettext solution is efficient but has the problem that >the translations can be done without any control, i.e. you simply change a >text file. > > Seems like database could be changed just as easily and that most users who could figure out how to change the file could figure out how to change the db... am I missing something? >I also enlarged the db column containing the label identifier: now it's 100 >chars and can be enlarged again. > > I'm not sure that a DB backend to this is the way to go. That's going to make upgrade scripts a nightmare, plus you a have a whole new table to worry about perfomance on. I'd also worry about your mention to just have all the translations in the $lang[] array. That certainly should not be populated out of the DB on every page load... >As you can understand, using this approach I am addressing your main concern, >which is maintaining the code easy to read. >But also I am addressing my 2 concerns: having the application working at any >time, even during translation, and having a simple way to translate without >the danger of destroying the application. These issues are very important to >me; since I believe that a translator have to be free to see exactly where a >certain sentence appears, in order to deeply understand the meaning and give a >proper translation. A translation with the gettext approach is done without >simultaneously looking at the application. Using my approach you can have one >browser on the application and the other one in the application created for >translation (i.e. some php pages that show the original and let you write the >translation in a form) > > The worst I've seen that may cause a problem is the caching the apache or php supposedly does on strings - I've read many times that you need to restart apache every time you change a PO/MO file... I've never translated anything, but it would seem that between a file of strings and being able to look at the running application, it would not be that hard to do... they would just have to wait to actually see the translations on the page... The strings in the gettext PO files do at least reference the page (and line no if the translator can pick through code)... Real time updating of strings could be hard anyway (once you see the English that come from creating a Purch Order, you will really have no other choice but to create another Purch Order and submit it after the translations are done to see if you changed things correctly). >Now I am trying to solve the problem of parameters within a sentence, and in >particular the fact that the position of parameters can change from one >language to another (see the english-german example in the gettext >documentation).. > > A legitimate concern... you will likely run into the same problems I had testing gettext to handle the same (which was not easily done). An answer on how to do it correctly is likely in the code to the gettext replacement I mentioned a few posts ago, but I have not yet looked through its code to see how they handled it. jesse |
|
From: Daintrees <p.d...@pa...> - 2004-09-07 01:27:04
|
Glad to have you back Luca.
As noted previosuly, I am also very keen on having the ability to mak=
e
translations in a web-form that feed through into the application
immediately. I have been exchanging email with Rom regarding this and=
have
basically spec'd up the way this could be done by reading in a meesag=
es.po
file and showing the original msgid strings and the following msgstr =
string.
Having edited and re-written the messages.po file using a simple php =
scrip
behind the scenes re-running the gettext utility to create the .mo fi=
le.
Stopping and starting apache does not seem to be required. Rom is kee=
n to
get into this project - it would certainly have wider appeal than jus=
t
webERP and would give us the advantages you are seeking as well as th=
e
generic localisation code used by most php applications.
The way we have things will allow for the translation effort to proce=
ed with
no impact on the usability of the system.
The two issues important to you are also citical for me to:
1. having the application working at any time, even during translati=
on
2. having a simple way to translate without the danger of destroying=
the
application.
We have to modify the scripts under either scenario - the gettext met=
hod I
believe will be a heck of a lot less work and could be done with conc=
erted
effort by us all within the month.
The .po file can be edited at will an copied around for translators t=
o work
on at their leisure - notebook or wherever without connectivity. The =
system
still clicks over. Using the web form translation proposed by Rom thi=
s could
also be done on line.
Having gone a little way down this track I feel committed to this app=
roach
Luca. The web-form editing application Rom has suggested also looks t=
o
address our key concerns too.
>A translation with the gettext approach is done without
> simultaneously looking at the application.
This is a problem although the .po file does tell you in which script=
the
string appears - so you can look at the english application.
All approaches are a compromise and with the method we have chosen - =
I think
we can build a pretty good system.
Phil
----- Original Message -----=20
=46rom: "ing. Luca Turlon Don=E0" <luc...@pd...>
To: <web...@li...>
Sent: Tuesday, September 07, 2004 2:34 AM
Subject: [Web-erp-developers] Italian Translation
> Hello Phil,
> sorry for my silence, but I had some troubles that kept me away fro=
m work.
> I've seen that you started to work on the gettext solution.
>
> I've spent some time last week to study the approach of gettext, an=
d my
> opinion is that we the gettext solution is efficient but has the pr=
oblem
that
> the translations can be done without any control, i.e. you simply c=
hange a
> text file.
>
> Given thsi I have started thinking how I could get the best from th=
e
gettext
> approach and still keeping the db repository for the languages.
> I made some experiment and sorted out the following.
>
> In my "language.php" file I've defined a function translate(), whic=
h
receives
> a parameter which can be a string or an identifier. The function us=
es the
> $lang array, which contains all the translations needed, and which =
is
loaded
> at the beginning.
>
> function translate($idOfLabelToBeTranslated)
> {
> global $lang;
> if ($lang[$idOfLabelToBeTranslated]!=3Dnull)
> return $lang[$idOfLabelToBeTranslated];
> else
> return $idOfLabelToBeTranslated;
> }
>
> As you can see translate simply returns the translated message, whi=
ch has
then
> to be echoed (so it is very similar to gettext_noop...)
>
> I also enlarged the db column containing the label identifier: now =
it's
100
> chars and can be enlarged again.
> Since $idOfLabelToBeTranslated can be a string you can maintain cod=
e
> readability, as you can see in the following chunk of code from
> SelectCustomer.php
>
> ....
> if ($_POST['Search']=3D=3Dtranslate("Search Now")){
>
> If ($_POST['Keywords'] AND $_POST['CustCode']) {
> $msg=3D translate("Customer name keywords have been used in
> preference to the customer code extract entered.");
> $_POST["Keywords"] =3D strtoupper($_POST["Keywords"]);
> }
> If ($_POST['Keywords']=3D=3D"" AND $_POST['CustCode']=3D=3D"") {
> $msg=3Dtranslate("At least one customer name keyword OR an
> extract of a customer code must be entered for the search");
> .....
>
> As you can understand, using this approach I am addressing your mai=
n
concern,
> which is maintaining the code easy to read.
>
> But also I am addressing my 2 concerns: having the application work=
ing at
any
> time, even during translation, and having a simple way to translate
without
> the danger of destroying the application. These issues are very imp=
ortant
to
> me; since I believe that a translator have to be free to see exactl=
y where
a
> certain sentence appears, in order to deeply understand the meaning=
and
give a
> proper translation. A translation with the gettext approach is done
without
> simultaneously looking at the application. Using my approach you ca=
n have
one
> browser on the application and the other one in the application cre=
ated
for
> translation (i.e. some php pages that show the original and let you=
write
the
> translation in a form)
>
> Now I am trying to solve the problem of parameters within a sentenc=
e, and
in
> particular the fact that the position of parameters can change from=
one
> language to another (see the english-german example in the gettext
> documentation)..
>
> Finally: Phil, if you don't like this approach, i am going to bend =
down
and
> conform to you decision. The use of "translate" function is exactly=
as
> gettext_noop, so it'll be easy to adapt. But please first try to co=
nsider
the
> db solution.
> Luca
>
>
> -------------------------------------------------------
> 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=3D5047&alloc_id=3D10808&op=3Dclick
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
|
|
From: Jesse P. <je...@st...> - 2004-09-07 22:27:26
|
From the discussions the past few days, I'm kinda confused as to if or
which translation technique has been settled/re-settled on.
Should we be progressing with the _() method? going with some other
syntax/functions to support strings w/ embedded variables? something else?
Phil - can you point me straight?
jesse
Daintrees wrote:
>Glad to have you back Luca.
>
>As noted previosuly, I am also very keen on having the ability to make
>translations in a web-form that feed through into the application
>immediately. I have been exchanging email with Rom regarding this and have
>basically spec'd up the way this could be done by reading in a meesages.po
>file and showing the original msgid strings and the following msgstr string.
>Having edited and re-written the messages.po file using a simple php scrip
>behind the scenes re-running the gettext utility to create the .mo file.
>Stopping and starting apache does not seem to be required. Rom is keen to
>get into this project - it would certainly have wider appeal than just
>webERP and would give us the advantages you are seeking as well as the
>generic localisation code used by most php applications.
>
>The way we have things will allow for the translation effort to proceed with
>no impact on the usability of the system.
>
>The two issues important to you are also citical for me to:
>
>1. having the application working at any time, even during translation
>2. having a simple way to translate without the danger of destroying the
>application.
>
>We have to modify the scripts under either scenario - the gettext method I
>believe will be a heck of a lot less work and could be done with concerted
>effort by us all within the month.
>
>The .po file can be edited at will an copied around for translators to work
>on at their leisure - notebook or wherever without connectivity. The system
>still clicks over. Using the web form translation proposed by Rom this could
>also be done on line.
>
>Having gone a little way down this track I feel committed to this approach
>Luca. The web-form editing application Rom has suggested also looks to
>address our key concerns too.
>
>
>
>>A translation with the gettext approach is done without
>>simultaneously looking at the application.
>>
>>
>
>This is a problem although the .po file does tell you in which script the
>string appears - so you can look at the english application.
>
>All approaches are a compromise and with the method we have chosen - I think
>we can build a pretty good system.
>
>Phil
>
>----- Original Message -----
>From: "ing. Luca Turlon Donà" <luc...@pd...>
>To: <web...@li...>
>Sent: Tuesday, September 07, 2004 2:34 AM
>Subject: [Web-erp-developers] Italian Translation
>
>
>
>
>>Hello Phil,
>>sorry for my silence, but I had some troubles that kept me away from work.
>>I've seen that you started to work on the gettext solution.
>>
>>I've spent some time last week to study the approach of gettext, and my
>>opinion is that we the gettext solution is efficient but has the problem
>>
>>
>that
>
>
>>the translations can be done without any control, i.e. you simply change a
>>text file.
>>
>>Given thsi I have started thinking how I could get the best from the
>>
>>
>gettext
>
>
>>approach and still keeping the db repository for the languages.
>>I made some experiment and sorted out the following.
>>
>>In my "language.php" file I've defined a function translate(), which
>>
>>
>receives
>
>
>>a parameter which can be a string or an identifier. The function uses the
>>$lang array, which contains all the translations needed, and which is
>>
>>
>loaded
>
>
>>at the beginning.
>>
>>function translate($idOfLabelToBeTranslated)
>>{
>> global $lang;
>> if ($lang[$idOfLabelToBeTranslated]!=null)
>> return $lang[$idOfLabelToBeTranslated];
>> else
>> return $idOfLabelToBeTranslated;
>>}
>>
>>As you can see translate simply returns the translated message, which has
>>
>>
>then
>
>
>>to be echoed (so it is very similar to gettext_noop...)
>>
>>I also enlarged the db column containing the label identifier: now it's
>>
>>
>100
>
>
>>chars and can be enlarged again.
>>Since $idOfLabelToBeTranslated can be a string you can maintain code
>>readability, as you can see in the following chunk of code from
>>SelectCustomer.php
>>
>>....
>>if ($_POST['Search']==translate("Search Now")){
>>
>>If ($_POST['Keywords'] AND $_POST['CustCode']) {
>>$msg= translate("Customer name keywords have been used in
>>preference to the customer code extract entered.");
>>$_POST["Keywords"] = strtoupper($_POST["Keywords"]);
>>}
>>If ($_POST['Keywords']=="" AND $_POST['CustCode']=="") {
>>$msg=translate("At least one customer name keyword OR an
>>extract of a customer code must be entered for the search");
>>.....
>>
>>As you can understand, using this approach I am addressing your main
>>
>>
>concern,
>
>
>>which is maintaining the code easy to read.
>>
>>But also I am addressing my 2 concerns: having the application working at
>>
>>
>any
>
>
>>time, even during translation, and having a simple way to translate
>>
>>
>without
>
>
>>the danger of destroying the application. These issues are very important
>>
>>
>to
>
>
>>me; since I believe that a translator have to be free to see exactly where
>>
>>
>a
>
>
>>certain sentence appears, in order to deeply understand the meaning and
>>
>>
>give a
>
>
>>proper translation. A translation with the gettext approach is done
>>
>>
>without
>
>
>>simultaneously looking at the application. Using my approach you can have
>>
>>
>one
>
>
>>browser on the application and the other one in the application created
>>
>>
>for
>
>
>>translation (i.e. some php pages that show the original and let you write
>>
>>
>the
>
>
>>translation in a form)
>>
>>Now I am trying to solve the problem of parameters within a sentence, and
>>
>>
>in
>
>
>>particular the fact that the position of parameters can change from one
>>language to another (see the english-german example in the gettext
>>documentation)..
>>
>>Finally: Phil, if you don't like this approach, i am going to bend down
>>
>>
>and
>
>
>>conform to you decision. The use of "translate" function is exactly as
>>gettext_noop, so it'll be easy to adapt. But please first try to consider
>>
>>
>the
>
>
>>db solution.
>>Luca
>>
>>
>>-------------------------------------------------------
>>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_idP47&alloc_id808&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-07 10:19:44
|
> The worst I've seen that may cause a problem is the caching the apache > or php supposedly does on strings - I've read many times that you need > to restart apache every time you change a PO/MO file. In fact you can switch languages on the fly ie using our user settings script selecting it then change back to another language and the whole application instantly changes to the other .mo file. I am not sure why you would need to restart apache? Phil |
|
From: Daintrees <p.d...@pa...> - 2004-09-08 07:20:37
|
Team, 1. I don't want Luca grumpy and to walk away from the translation effort! He and Rom are the reason it is happening at all. Although Victor on the user list has been the biggest contributor of gettextified scripts to date. 2. I want webERP as solid as possible and its translation methodology and syntax as widely understood as possible - using industry standard tools. 3. I DON'T want to have to modify every script then after having done that, cut and paste every string in the system into a database as well. I've listened to Luca/Rom/Hani/Steve and Jesse - (Hani/Steve and Jesse all computer scientists and Hani having been involved in translation of application before) and whilst I accept there are some compromises with gettext I am completely convinced that if it's to be done then this is the approach we should go with. Readability - not bad! Ease of translation - all strings are extracted for us referenced back to the script they came from! The risk of introducing bugs is minimal - scripts will likely not parse if there is an error. We can still use the system while its being translated. Possibility for real time web based translation updates and maintenance As Jesse points out we may not have the perfect translation on the first cut - but the encapsulation of strings inside _( ) are where we should start. Lets deal with the variable positioning issue where it is a real problem later on. I see the pdf issue as more pressing persnonally. I especially hope Luca can live with this call. I really don't want to encumber the system with a potentially flaky/slower php gettext class either - if you want language translation you need to install gettext - see 2 above. The system will work without it in English. Phil |
×
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