web-erp-developers — Discussion on development of webERP

Re: [Web-erp-developers] Italian Translation

[Daintrees <p.d...@pa...>]

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

Re: [Web-erp-developers] file imports for serial items

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

I think it would be nice to include a software based gettext for those who
don't have it installed with php.  There are several reasons they may not
have it installed and may not be able to do so.  I believe there are some
software based gettext replicas around and possibly the one Jesse is
suggesting is the best.  Plus it does give the opportunity in the future to
do the embedded variables if we so desire down the road, even if not now.

I think the important reasons for staying on the current path are:

1) We've found the standard tools and method.  We know it is widely used and
works.  We know others have experience with it.
2) We have checked it all out to know what we're doing
3) It is not too complicated for everyone.  Everyone seems to readily
understand what to do which means more help too.
4) We are already down that path

So maybe it's better to continue that path.  There's no reason in the future
why we can't do round two where we change the strings back into one piece.
Granted Jesse is right that it is more work.  I think several systems on the
market do not go to the extent of translating with embedded variables so
having the language expressed poorly in some messages is not a necessity but
an advantage that could become a necessity in the future.  Either way it
would be nice to have eventually.

Steve

----- Original Message ----- 
From: "Daintrees" <p.d...@pa...>
To: <web...@li...>
Sent: Sunday, September 05, 2004 9:11 PM
Subject: Re: [Web-erp-developers] file imports for serial items


> Yes this is a good thought.
>
> The saving grace is that variables are very rarely used inside strings.
> Perhaps I am lazy, but I really don't see the need to go to great lengths
> for the 2 or 3 instances of where this happens.
>
> The fall back where gettext is not installed on the local server is to
> create a function that just returns the english string. Translated
> environments thus need gettext installed. I understand that gettext is
> pretty widely available on most web-hosts. It is widely used and tested in
> many environments. I am keen to stick with tried and true.
>
> Phil
>
> ----- Original Message ----- 
> From: "Jesse Peterson" <je...@st...>
> To: <web...@li...>
> Sent: Monday, September 06, 2004 9:18 AM
> Subject: Re: [Web-erp-developers] file imports for serial items
>
>
> >
> > >Pros
> > >1) We would need to evaluate how much further it gets the translation
> > >compared to not using.
> > >
> > >
> > I see it as allowing more accurate string/message translations however
> > it will require a little more code for the developers and a little extra
> > instruction to a translator (how to move around variables).
> >
> > >Cons
> > >1) The possible slowdowns of using the class instead of built in php
> > >processor gettext code
> > >
> > >
> > This class allows use of php's built-in gettext libraries if they are
> > available. This is important as I am pretty sure we could inter-mix it's
> > use with the standard gettext function, therefor only having to use it
> > when we needed a string with vars in it.
> >
> > >2) What's with the setVar?  Does that mean we need to add setVars for
> every
> > >var used in a string? That will be some more work.
> > >
> > >
> > >
> > Yes, and yes it will be a little more work.
> >
> > >3) Do the tolls for making the po's such as xgettext all work smoothly
> with
> > >this enhancement?
> > >
> > >
> > huh? It appears to use the same POs gen'd by xgettext if that's what you
> > are asking about.
> >
> > >4) If setVar is not done on a variable then I'm thinking what will
happen
> is
> > >the variable name with $ will appear instead of the variable's value.
> This
> > >could get easily missed by various people at various times.
> > >
> > >5) How stable and used is this class?
> > >
> > >
> > They use it and claim it is stable enough for their use. We will have to
> > test it/read docs to determine it's how it functions when mis-used.
> >
> > The main point here, though, is that I haven't seen a more simple way to
> > get things fully translated (as opposed to in pieces) than a wrapper
> > like this or through complicated (s)printfs. If others think the pieced
> > together translations will suffice, then so be it. I just would hate to
> > have gone through this trouble and find later that people really can't
> > stand the translations that have been done and to realize that with a
> > little extra work at the beginning they could have been better.
> >
> > jesse
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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

Re: [Web-erp-developers] Italian Translation

[Jesse P. <je...@st...>]

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

Re: [Web-erp-developers] Re: input & goods received mods

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

Couldn't say I was sure so I'm glad we figured out what was happening for
sure.

Just to emphasize, I'll repeat what you said so everyone knows or all the
pages will be incorrect.

Whoever is doing the pages for Multilanguage needs to move the line that
sets $title to a string near the top of every page to after the session.inc
include but before header.inc.  header.inc uses $title so it must be set and
translated before header.inc.

Steve

----- Original Message ----- 
From: "Jesse Peterson" <je...@st...>
To: <web...@li...>
Sent: Tuesday, September 07, 2004 4:58 PM
Subject: RE: [Web-erp-developers] Re: input & goods received mods


Ok, I took another look and realized I was just foolish in my original post.
You probably don't have gettext enabled.... I never actually looked, only
grep'd to see if the gettext stuff is in session.inc - it is included in
session.inc . Not having that function defined when gettext is not
functional has to be what is causing you problem.
So, I imagine to make Language support work across the board, your original
statement that session.inc needs to be the first include in every script is
dead-on.
Sorry to have caused doubt/confusion.


jesse

-----Original Message-----
From: skaill [mailto:sk...@ro...]
Sent: Tuesday, September 07, 2004 3:51 PM
To: web...@li...
Subject: Re: [Web-erp-developers] Re: input & goods received mods


If I put the $title line at the top before session.inc include then I get an
error.  I have not tampered with my session.auto_start or any other php
settings.  That was just information I passed on the other day but did not
try.  I'm thinking since the _() function is defined in session.inc as far
as I see this would mean that the $title translation call is before the
translation _() function is defined.  I can't remember if php sees all
functions in the includes whether before encountered or not though.  I'm
thinking not.

The error is

Fatal error: Call to undefined function: _() in
/home/weberp/public_html/weberpcvstest/BankAccounts.php on line 4

when $title is before the session.inc include.

Steve

----- Original Message ----- 
From: "Jesse Peterson" <je...@st...>
To: <web...@li...>
Sent: Monday, September 06, 2004 11:54 AM
Subject: Re: [Web-erp-developers] Re: input & goods received mods


>
> >That is interesting that you had to include session.inc before $title
> >was set. This doesn't appear necessary in php 5 and I have not done this
> >in the scripts I have modified - I will go back and modify them. I
> >thought it would be necessary initially.
> >
> >
> I don't have this problem ... I even see some scripts I am running out
> of yesterday's CVS  have this change made and seem to work fine. Steve,
> maybe this is a result of mucking with the session.auto_start variable
> you mentioned in a post some days ago?? For the record, I am running
> under php 4.3.4 .


-------------------------------------------------------
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=ick
_______________________________________________
Web-erp-developers mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

RE: [Web-erp-developers] Re: input & goods received mods

[Jesse P. <je...@st...>]

Ok, I took another look and realized I was just foolish in my original =
post. You probably don't have gettext enabled.... I never actually =
looked, only grep'd to see if the gettext stuff is in session.inc - it =
is included in session.inc . Not having that function defined when =
gettext is not functional has to be what is causing you problem.=20
So, I imagine to make Language support work across the board, your =
original statement that session.inc needs to be the first include in =
every script is dead-on.
Sorry to have caused doubt/confusion.


jesse

-----Original Message-----
From: skaill [mailto:sk...@ro...]
Sent: Tuesday, September 07, 2004 3:51 PM
To: web...@li...
Subject: Re: [Web-erp-developers] Re: input & goods received mods


If I put the $title line at the top before session.inc include then I =
get an
error.  I have not tampered with my session.auto_start or any other php
settings.  That was just information I passed on the other day but did =
not
try.  I'm thinking since the _() function is defined in session.inc as =
far
as I see this would mean that the $title translation call is before the
translation _() function is defined.  I can't remember if php sees all
functions in the includes whether before encountered or not though.  I'm
thinking not.

The error is

Fatal error: Call to undefined function: _() in
/home/weberp/public_html/weberpcvstest/BankAccounts.php on line 4

when $title is before the session.inc include.

Steve

----- Original Message -----=20
From: "Jesse Peterson" <je...@st...>
To: <web...@li...>
Sent: Monday, September 06, 2004 11:54 AM
Subject: Re: [Web-erp-developers] Re: input & goods received mods


>
> >That is interesting that you had to include session.inc before $title
> >was set. This doesn't appear necessary in php 5 and I have not done =
this
> >in the scripts I have modified - I will go back and modify them. I
> >thought it would be necessary initially.
> >
> >
> I don't have this problem ... I even see some scripts I am running out
> of yesterday's CVS  have this change made and seem to work fine. =
Steve,
> maybe this is a result of mucking with the session.auto_start variable
> you mentioned in a post some days ago?? For the record, I am running
> under php 4.3.4 .

Re: [Web-erp-developers] Rereading the .mo file

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

Only one came through that time!

----- Original Message ----- 
From: "Jesse Peterson" <je...@st...>
To: <web...@li...>
Sent: Tuesday, September 07, 2004 4:11 PM
Subject: RE: [Web-erp-developers] Rereading the .mo file


geeezzz! I found a queue problem earlier today and fixed it. Let me know if
you get more dupes!!
sorry!

jesse

-----Original Message-----
From: Daintrees [mailto:p.d...@pa...]
Sent: Tuesday, September 07, 2004 3:59 PM
To: web...@li...
Subject: Re: [Web-erp-developers] Rereading the .mo file


Got this one 4 times!

Phil
----- Original Message ----- 
From: "Jesse Peterson" <je...@st...>
To: <web...@li...>
Sent: Tuesday, September 07, 2004 11:46 PM
Subject: RE: [Web-erp-developers] Rereading the .mo file


> >> 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
>
> Sorry, I was just repeating what I read, not what I tested. You'll see
even in the PHP dpc comments people say that:
> http://us4.php.net/manual/en/ref.gettext.php
>
> If that's not the case, then all the better, though we may want to beware
that it may end up being an issue for other's at somepoint (albeit a small
issue since most people won't be mucking around with the mo/po files).
>
>
> jesse
>
>
> -------------------------------------------------------
> 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Ìk
> _______________________________________________
> 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=ick
_______________________________________________
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=ick
_______________________________________________
Web-erp-developers mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

RE: [Web-erp-developers] Rereading the .mo file

[Jesse P. <je...@st...>]

geeezzz! I found a queue problem earlier today and fixed it. Let me know =
if you get more dupes!!
sorry!

jesse

-----Original Message-----
From: Daintrees [mailto:p.d...@pa...]
Sent: Tuesday, September 07, 2004 3:59 PM
To: web...@li...
Subject: Re: [Web-erp-developers] Rereading the .mo file


Got this one 4 times!

Phil
----- Original Message -----=20
From: "Jesse Peterson" <je...@st...>
To: <web...@li...>
Sent: Tuesday, September 07, 2004 11:46 PM
Subject: RE: [Web-erp-developers] Rereading the .mo file


> >> 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
>
> Sorry, I was just repeating what I read, not what I tested. You'll see
even in the PHP dpc comments people say that:
> http://us4.php.net/manual/en/ref.gettext.php
>
> If that's not the case, then all the better, though we may want to =
beware
that it may end up being an issue for other's at somepoint (albeit a =
small
issue since most people won't be mucking around with the mo/po files).
>
>
> jesse
>
>
> -------------------------------------------------------
> 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_id=10808&op=CCk
> _______________________________________________
> 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_id=10808&op=3Dick
_______________________________________________
Web-erp-developers mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [Web-erp-developers] Re: input & goods received mods

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

If I put the $title line at the top before session.inc include then I get an
error.  I have not tampered with my session.auto_start or any other php
settings.  That was just information I passed on the other day but did not
try.  I'm thinking since the _() function is defined in session.inc as far
as I see this would mean that the $title translation call is before the
translation _() function is defined.  I can't remember if php sees all
functions in the includes whether before encountered or not though.  I'm
thinking not.

The error is

Fatal error: Call to undefined function: _() in
/home/weberp/public_html/weberpcvstest/BankAccounts.php on line 4

when $title is before the session.inc include.

Steve

----- Original Message ----- 
From: "Jesse Peterson" <je...@st...>
To: <web...@li...>
Sent: Monday, September 06, 2004 11:54 AM
Subject: Re: [Web-erp-developers] Re: input & goods received mods


>
> >That is interesting that you had to include session.inc before $title
> >was set. This doesn't appear necessary in php 5 and I have not done this
> >in the scripts I have modified - I will go back and modify them. I
> >thought it would be necessary initially.
> >
> >
> I don't have this problem ... I even see some scripts I am running out
> of yesterday's CVS  have this change made and seem to work fine. Steve,
> maybe this is a result of mucking with the session.auto_start variable
> you mentioned in a post some days ago?? For the record, I am running
> under php 4.3.4 .
>
>
> jesse
>
>
> -------------------------------------------------------
> 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

Re: [Web-erp-developers] Rereading the .mo file

[Daintrees <p.d...@pa...>]

Got this one 4 times!

Phil
----- Original Message -----=20
=46rom: "Jesse Peterson" <je...@st...>
To: <web...@li...>
Sent: Tuesday, September 07, 2004 11:46 PM
Subject: RE: [Web-erp-developers] Rereading the .mo file


> >> 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 yo=
u 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 set=
tings
> > script selecting it then change back to another language and the =
whole
> > application instantly changes to the other .mo file. I am not sur=
e why
> > you would need to restart apache?
> > Phil
>
> Sorry, I was just repeating what I read, not what I tested. You'll =
see
even in the PHP dpc comments people say that:
> http://us4.php.net/manual/en/ref.gettext.php
>
> If that's not the case, then all the better, though we may want to =
beware
that it may end up being an issue for other's at somepoint (albeit a =
small
issue since most people won't be mucking around with the mo/po files)=
.
>
>
> jesse
>
>
> -------------------------------------------------------
> 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_id=10808&op=CCk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>

Re: [Web-erp-developers] Re: input & goods received mods

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

Thanks, Jesse, I'll check it out again.  

Steve

----- Original Message ----- 
From: "Jesse Peterson" <je...@st...>
To: <web...@li...>
Sent: Monday, September 06, 2004 11:54 AM
Subject: Re: [Web-erp-developers] Re: input & goods received mods


> 
> >That is interesting that you had to include session.inc before $title
> >was set. This doesn't appear necessary in php 5 and I have not done this
> >in the scripts I have modified - I will go back and modify them. I
> >thought it would be necessary initially.
> >  
> >
> I don't have this problem ... I even see some scripts I am running out 
> of yesterday's CVS  have this change made and seem to work fine. Steve, 
> maybe this is a result of mucking with the session.auto_start variable 
> you mentioned in a post some days ago?? For the record, I am running 
> under php 4.3.4 .
> 
> 
> jesse
> 
> 
> -------------------------------------------------------
> 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

Re: [Web-erp-developers] Re: input & goods received mods

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

Well, I guess as far as testing we should pill up each changed script and
see if all the English words displayed still appear properly.  This makes
sure we didn't do anything horrible with the string splittings, we haven't
hard coded a variable name in single quotes, etc.

Steve

----- Original Message ----- 
From: "Phil Daintree" <we...@pa...>
To: <web...@li...>
Sent: Monday, September 06, 2004 3:43 AM
Subject: Re: [Web-erp-developers] Re: input & goods received mods


> Steve,
>
> That script looks fine - I have tested and updated the CVS.
>
> This is a difficulty with the approach - we can only xgettext the
> strings to translate having modified the code to perform the translation
> - so we cannot actually test the translation code works until we create
> the messages.po file get the msgstr translated and create a messages.mo
> file. I have proved the concept though and if you update your cvs and
> switch to italian you should see my foolish translations of a couple of
> menu items! As I get these scripts I will extract the strings and build
> up our messages.po file ready for translation.
>
> In our case the modification of the scripts as you describe is required
> first - the translation itself is not testable until we have a
> messages.po and all the strings have been translated - also a massive
> job!
>
> That is interesting that you had to include session.inc before $title
> was set. This doesn't appear necessary in php 5 and I have not done this
> in the scripts I have modified - I will go back and modify them. I
> thought it would be necessary initially.
>
> The only other thing I would like to acheive is to convert to Jesse's
> DB_query with the additional parameters - this actually reduces a fair
> amount of repeated code - wish I'd thought of it before really. Need to
> be a little careful inside pdf scripts though.
>
>
>
> Phil
>
>
> On Mon, 2004-09-06 at 03:30, skaill wrote:
> > Hi Phil,
> >
> > Here's my first Multilanguage file.  It is BankAccounts.  Would you be
able
> > to check it out and let me know if I'm doing everything right.  What I
> > understand is
> >
> > 1) Change all the strings to be encapsulated by the _() translation
function
> > call.  These would be in echo and printf statements as well as
comparisons
> > possibly but one must be careful about them.  Also table column headers,
> > field labels and such within the html.
> >
> > 2)  Check to make sure any submits are using isset to avoid translation.
> > I'm assuming here that you haven't overloaded multiple submit buttons
with
> > the same name but different values.
> >
> > 3) Changing the double quotes to single quotes for strings wherever
possible
> > and breaking the strings into pieces where there are variables.
> >
> > One concern I have is how to test this properly.  I went as far as
putting
> > my changes up on our test site and the page looks fine but it isn't
doing
> > any real translation, it's just coming back with the English.  Who is
> > creating the actual language file that we could use to test?
> >
> > I ran into two problems and one could be because I haven't updated my
cvs in
> > a day or two.
> >
> > 1) It gave an error the first time it encountered a call to _() saying
the
> > function didn't exist.  I modified the gettext part in session.inc to
> >
> > if (!function_exists('gettext')){
> >  function _($text){
> >   return $text;
> >  }
> > } else {
> >   function _($text) {
> >    return gettext($text);
> >  }
> > }
> >
> > 2) The $title variable is at the top of each script but the include for
> > session.inc that defines the _() function is afterward.  So, if you
change
> > $title to _($title) there is an error about undefined function.  I fixed
it
> > by moving the $title below the session.inc include but before the
header.inc
> > which uses $title!
> >
> > I know my message is long but I want to get this right from the start
> > instead of having to go back through all the files I do a second time.
That
> > wouldn't be fun :O
> >
> > Steve
> >
> > ----- Original Message ----- 
> > From: "Phil Daintree" <we...@pa...>
> > To: <web...@li...>
> > Sent: Sunday, September 05, 2004 4:30 AM
> > Subject: [Web-erp-developers] Re: input & goods received mods
> >
> >
> > > Huge enthusiasm boost!!
> > > Thanks Jesse.
> > >
> > > I came accross a couple of links that were stuffed by the change to '
> > > rather than " and a missed < somewhere but so easy to apply with a
diff
> > > and the files themselves - it is just a question of reviewing the diff
> > > and copying the file!!
> > >
> > > Would you have any more time for other scripts perhaps staying with
the
> > > controlled/serialized stuff??
> > >
> > > StockAdjustments.php
> > > StockAdjustmentsControlled.php
> > > StockTransferControlled.php
> > > StockTransfers.php
> > >
> > >
> > > For the benefit of the rest of the crew ... these are now in CVS - all
> > > gettextified thanks to Jesse
> > >
> > > GoodsReceived.php
> > > GoodsReceivedControlled.php
> > > and accompanying includes
> > > includes/InputSerialItems.php
> > > includes/InputSerialItemsKeyed.php
> > > includes/InputSerialItemsFile.php
> > >
> > >
> > > I also managed to enslist Victor off the user list and he has _ified
> > >
> > > Customers.php
> > >
> > > Together with my own meagre efforts:
> > >
> > > AccountGroups.php
> > > AgedDebtors.php  includes/PDFAgedDebtorsPageHeader.inc
> > > AgedSuppliers.php includes/PDFAgedSuppliersPageHeader.inc
> > >
> > > So we are rattling through them!
> > >
> > > Phil
> > >
> > >
> > > On Sun, 2004-09-05 at 18:17, Jesse Peterson wrote:
> > > > I've attached a diff of my changes as well as the full files.
> > > >
> > > > Most all of the changes are for translations and changing "s to 's.
The
> > > > form setting 'enctype' that fixed my upload issue is included, and a
> > > > small error in an upgrade script is as well.
> > > >
> > > > These changes are against cvs pulled around 9/14 16:19 EDT.
> > > >
> > > >
> > > > jesse
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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

RE: [Web-erp-developers] Rereading the .mo file

[Jesse P. <je...@st...>]

>> The worst I've seen that may cause a problem is the caching the =
apache=20
>> or php supposedly does on strings - I've read many times that you =
need=20
>> 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

Sorry, I was just repeating what I read, not what I tested. You'll see =
even in the PHP dpc comments people say that:
http://us4.php.net/manual/en/ref.gettext.php

If that's not the case, then all the better, though we may want to =
beware that it may end up being an issue for other's at somepoint =
(albeit a small issue since most people won't be mucking around with the =
mo/po files).


jesse

Re: [Web-erp-developers] Re: input & goods received mods

[Phil D. <we...@pa...>]

> I don't have this problem ... I even see some scripts I am running out 
> of yesterday's CVS  have this change made and seem to work fine. Steve, 
> maybe this is a result of mucking with the session.auto_start variable 
> you mentioned in a post some days ago?? For the record, I am running 
> under php 4.3.4 .
> 

Steve,

With session.auto_start I would have thought php would have started the
session before it gets to parse the set php.ini bit? I haven't tried it
and it sure would limit the scope for problems. I'll give it a go when
we are translated.

Phil

[Web-erp-developers] Rereading the .mo file

[Phil D. <we...@pa...>]

> 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

Re: [Web-erp-developers] Re: Converted Customers.php for multi-language support

[Phil D. <we...@pa...>]

Fantastic!

There is only one tiny issue .... calls to the DB_query function like
the following:

	$CustomerResult = DB_query($SQL,$db);

	if (DB_error_no($db) !=0) {
		echo _('The customer details could not be retrieved by the SQL
because') . ' - ' . DB_error_msg($db);

		if ($debug==1){
			echo '<BR>' . $SQL;
		}
		exit;
	}

becomes:

$ErrMsg = _('The customer details could not be retrieved because');
$DbgMsg = _('The SQL that failed was');
$CustomerResult = DB_query($SQL,$db,$ErrMsg, $DbgMsg);

This was a change made by Jesse to the DB_query function to avoid all
the repetition of the first lot of code.

I have changed them all over now.

Thanks for all your help and I am bound to ask (I am now pushing it a
bit) ... would you do a few more?


DiscountCategories.php
DiscountMatrix.php

Phil


On Tue, 2004-09-07 at 17:41, Victor wrote:
> Hi Phil,
> 
> Yesterday, I could only finish the conversion of CustomerReceipt.php
> Today, I also finish the other script CustomerTransInquiry.php
> Please check them and let me know whether there is any error.
> Thanks!
> 
> Victor
> 
> ----- Original Message ----- 
> From: "Phil Daintree" <we...@pa...>
> To: "Victor" <vi...@hi...>;
> <web...@li...>
> Sent: Saturday, September 04, 2004 1:30 PM
> Subject: Re: Converted Customers.php for multi-language support
> 
> 
> > Perfect!
> > I notice you have even changed to single ' to improve performance!
> >
> > I have committed this to the CVS.
> >
> > Many thanks!
> >
> > Could I impose on you for a few more scripts?
> >
> > CustomerReceipt.php
> > CustomerTransInquiry.php
> >
> > Thanks
> >
> > Phil
> >
> > On Sat, 2004-09-04 at 01:02, Victor wrote:
> > > Hi Phil,
> > >
> > > It seems that Customers.php is not a difficult script to be converted
> > > for multi-language support.
> > > Therefore I have made the conversion. Please take a look and let me
> > > know whether there is any mistake.
> > >
> > > Regards,
> > > Victor
> >

[Web-erp-developers] Re: Converted Customers.php for multi-language support

[Victor <vi...@hi...>]

Hi Phil,

Yesterday, I could only finish the conversion of CustomerReceipt.php
Today, I also finish the other script CustomerTransInquiry.php
Please check them and let me know whether there is any error.
Thanks!

Victor

----- Original Message ----- 
From: "Phil Daintree" <we...@pa...>
To: "Victor" <vi...@hi...>;
<web...@li...>
Sent: Saturday, September 04, 2004 1:30 PM
Subject: Re: Converted Customers.php for multi-language support


> Perfect!
> I notice you have even changed to single ' to improve performance!
>
> I have committed this to the CVS.
>
> Many thanks!
>
> Could I impose on you for a few more scripts?
>
> CustomerReceipt.php
> CustomerTransInquiry.php
>
> Thanks
>
> Phil
>
> On Sat, 2004-09-04 at 01:02, Victor wrote:
> > Hi Phil,
> >
> > It seems that Customers.php is not a difficult script to be converted
> > for multi-language support.
> > Therefore I have made the conversion. Please take a look and let me
> > know whether there is any mistake.
> >
> > Regards,
> > Victor
>

Re: [Web-erp-developers] Italian Translation

[Daintrees <p.d...@pa...>]

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
>

Re: [Web-erp-developers] Italian Translation

[Jesse P. <je...@st...>]

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

Re: [Web-erp-developers] Re: input & goods received mods

[Jesse P. <je...@st...>]

>That is interesting that you had to include session.inc before $title
>was set. This doesn't appear necessary in php 5 and I have not done this
>in the scripts I have modified - I will go back and modify them. I
>thought it would be necessary initially.
>  
>
I don't have this problem ... I even see some scripts I am running out 
of yesterday's CVS  have this change made and seem to work fine. Steve, 
maybe this is a result of mucking with the session.auto_start variable 
you mentioned in a post some days ago?? For the record, I am running 
under php 4.3.4 .


jesse

[Web-erp-developers] Italian Translation

[ing. L. Tur <luc...@pd...>]

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

[Web-erp-developers] ConfirmDispatch_Invoice.pjhp

[Phil D. <we...@pa...>]

I have been a little foolish - I started modifying the script for
gettext even though I asked Luca to do it and I know Jesse started to do
some work on it to. Please could you checkout the latest from CVS before
you guys get into this script.

Sorry!!

Phil

[Web-erp-developers] Translation Issues

[Phil D. <we...@pa...>]

Rom and Luca,

Really need some input from you chaps before we can go much further.

We have started converting the scripts to allow translation of the
messages to other languages. I have attached the translation file as we
have it. I dont propose that you start on the translations until we have
the scripts completed. The modifications are simple - but time consuming
since there is such a lot of it!

The issues are:

1. In some scripts there are variables interspersed with the text of a
message. We think that perhaps the positioning of the variable is
probably going to be different for other languages.
eg. The worst case I can find is an error report message from
ConfirmDispatch_Invoice.php I was working on earlier ....

echo "<BR>" . _('Orig order for') . ' ' . $myrow["StkCode"] . ' ' .
_('has a quantity of') . ' ' . $myrow["Quantity"] . ' ' . _('and an
invoiced quantity of') . ' ' . $myrow["QtyInvoiced"] . ' ' . _('the
session shows a quantity of') . ' ' .
$_SESSION['Items']->LineItems[$stkItm]->Quantity . ' ' . _('and a
quantity invoiced of') . ' ' .
$_SESSION['Items']->LineItems[$stkItm]->QtyInv;

The question is could you make sense of this by substitution of the
strings inside the _() function calls - the english that comes out of
this is dubious at best anyway. 

I am a little fearful that if you can't make any sensible translation of
such a string the additional complications could be tough. Jesse has an
alternative that we should look at.

2. PDF reporting using different locales with the pdf.php class needs
some research - or read I can't get them to work!!

Since the guys who have been doing the script work are just english
speakers we are a bit concerned that this may be a problem.

If you could take a look and let us know that would be most appreciated.

Thanks

Phil

Re: [Web-erp-developers] Re: input & goods received mods

[Phil D. <we...@pa...>]

Steve,

That script looks fine - I have tested and updated the CVS.

This is a difficulty with the approach - we can only xgettext the
strings to translate having modified the code to perform the translation
- so we cannot actually test the translation code works until we create
the messages.po file get the msgstr translated and create a messages.mo
file. I have proved the concept though and if you update your cvs and
switch to italian you should see my foolish translations of a couple of
menu items! As I get these scripts I will extract the strings and build
up our messages.po file ready for translation.

In our case the modification of the scripts as you describe is required
first - the translation itself is not testable until we have a
messages.po and all the strings have been translated - also a massive
job! 

That is interesting that you had to include session.inc before $title
was set. This doesn't appear necessary in php 5 and I have not done this
in the scripts I have modified - I will go back and modify them. I
thought it would be necessary initially.

The only other thing I would like to acheive is to convert to Jesse's
DB_query with the additional parameters - this actually reduces a fair
amount of repeated code - wish I'd thought of it before really. Need to
be a little careful inside pdf scripts though.



Phil


On Mon, 2004-09-06 at 03:30, skaill wrote:
> Hi Phil,
> 
> Here's my first Multilanguage file.  It is BankAccounts.  Would you be able
> to check it out and let me know if I'm doing everything right.  What I
> understand is
> 
> 1) Change all the strings to be encapsulated by the _() translation function
> call.  These would be in echo and printf statements as well as comparisons
> possibly but one must be careful about them.  Also table column headers,
> field labels and such within the html.
> 
> 2)  Check to make sure any submits are using isset to avoid translation.
> I'm assuming here that you haven't overloaded multiple submit buttons with
> the same name but different values.
> 
> 3) Changing the double quotes to single quotes for strings wherever possible
> and breaking the strings into pieces where there are variables.
> 
> One concern I have is how to test this properly.  I went as far as putting
> my changes up on our test site and the page looks fine but it isn't doing
> any real translation, it's just coming back with the English.  Who is
> creating the actual language file that we could use to test?
> 
> I ran into two problems and one could be because I haven't updated my cvs in
> a day or two.
> 
> 1) It gave an error the first time it encountered a call to _() saying the
> function didn't exist.  I modified the gettext part in session.inc to
> 
> if (!function_exists('gettext')){
>  function _($text){
>   return $text;
>  }
> } else {
>   function _($text) {
>    return gettext($text);
>  }
> }
> 
> 2) The $title variable is at the top of each script but the include for
> session.inc that defines the _() function is afterward.  So, if you change
> $title to _($title) there is an error about undefined function.  I fixed it
> by moving the $title below the session.inc include but before the header.inc
> which uses $title!
> 
> I know my message is long but I want to get this right from the start
> instead of having to go back through all the files I do a second time.  That
> wouldn't be fun :O
> 
> Steve
> 
> ----- Original Message ----- 
> From: "Phil Daintree" <we...@pa...>
> To: <web...@li...>
> Sent: Sunday, September 05, 2004 4:30 AM
> Subject: [Web-erp-developers] Re: input & goods received mods
> 
> 
> > Huge enthusiasm boost!!
> > Thanks Jesse.
> >
> > I came accross a couple of links that were stuffed by the change to '
> > rather than " and a missed < somewhere but so easy to apply with a diff
> > and the files themselves - it is just a question of reviewing the diff
> > and copying the file!!
> >
> > Would you have any more time for other scripts perhaps staying with the
> > controlled/serialized stuff??
> >
> > StockAdjustments.php
> > StockAdjustmentsControlled.php
> > StockTransferControlled.php
> > StockTransfers.php
> >
> >
> > For the benefit of the rest of the crew ... these are now in CVS - all
> > gettextified thanks to Jesse
> >
> > GoodsReceived.php
> > GoodsReceivedControlled.php
> > and accompanying includes
> > includes/InputSerialItems.php
> > includes/InputSerialItemsKeyed.php
> > includes/InputSerialItemsFile.php
> >
> >
> > I also managed to enslist Victor off the user list and he has _ified
> >
> > Customers.php
> >
> > Together with my own meagre efforts:
> >
> > AccountGroups.php
> > AgedDebtors.php  includes/PDFAgedDebtorsPageHeader.inc
> > AgedSuppliers.php includes/PDFAgedSuppliersPageHeader.inc
> >
> > So we are rattling through them!
> >
> > Phil
> >
> >
> > On Sun, 2004-09-05 at 18:17, Jesse Peterson wrote:
> > > I've attached a diff of my changes as well as the full files.
> > >
> > > Most all of the changes are for translations and changing "s to 's. The
> > > form setting 'enctype' that fixed my upload issue is included, and a
> > > small error in an upgrade script is as well.
> > >
> > > These changes are against cvs pulled around 9/14 16:19 EDT.
> > >
> > >
> > > jesse
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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

[Web-erp-developers] Avoiding Choppy Translations

[Daintrees <p.d...@pa...>]

I got this message 5 times.
Is this a list issue or are you trying to make a point Jesse!!

Although I haven't come accross this much - the point is well made. We
should get Luca/Rom to take a look at this when they back into it.

Phil
----- Original Message ----- 
From: "Jesse Peterson" <je...@st...>
To: <web...@li...>
Sent: Monday, September 06, 2004 3:26 PM
Subject: Re: [Web-erp-developers] file imports for serial items


> I'd have to say it happens more than rarely. Again, my big worry is
> choppy, nonsensical  translations putting off potential users. I also
> believe that using a wrapper class, including the one I mentioned, would
> allow us to *only* use it when necessary and the _('xxx') to be used
> every other time.
> Maybe we need to get some people doing or that can do translations to
> take a look and see what effect it may have. It's just something that
> would be nice to get right the first time since there are well over 150
> scripts that have to follow which ever way we determine as best.
>
> jesse
>
>
> Daintrees wrote:
>
> >Yes this is a good thought.
> >
> >The saving grace is that variables are very rarely used inside strings.
> >Perhaps I am lazy, but I really don't see the need to go to great lengths
> >for the 2 or 3 instances of where this happens.
> >
> >The fall back where gettext is not installed on the local server is to
> >create a function that just returns the english string. Translated
> >environments thus need gettext installed. I understand that gettext is
> >pretty widely available on most web-hosts. It is widely used and tested
in
> >many environments. I am keen to stick with tried and true.
> >
> >Phil
> >
> >----- Original Message ----- 
> >From: "Jesse Peterson" <je...@st...>
> >To: <web...@li...>
> >Sent: Monday, September 06, 2004 9:18 AM
> >Subject: Re: [Web-erp-developers] file imports for serial items
> >
> >
> >
> >
> >>>Pros
> >>>1) We would need to evaluate how much further it gets the translation
> >>>compared to not using.
> >>>
> >>>
> >>>
> >>>
> >>I see it as allowing more accurate string/message translations however
> >>it will require a little more code for the developers and a little extra
> >>instruction to a translator (how to move around variables).
> >>
> >>
> >>
> >>>Cons
> >>>1) The possible slowdowns of using the class instead of built in php
> >>>processor gettext code
> >>>
> >>>
> >>>
> >>>
> >>This class allows use of php's built-in gettext libraries if they are
> >>available. This is important as I am pretty sure we could inter-mix it's
> >>use with the standard gettext function, therefor only having to use it
> >>when we needed a string with vars in it.
> >>
> >>
> >>
> >>>2) What's with the setVar?  Does that mean we need to add setVars for
> >>>
> >>>
> >every
> >
> >
> >>>var used in a string? That will be some more work.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>Yes, and yes it will be a little more work.
> >>
> >>
> >>
> >>>3) Do the tolls for making the po's such as xgettext all work smoothly
> >>>
> >>>
> >with
> >
> >
> >>>this enhancement?
> >>>
> >>>
> >>>
> >>>
> >>huh? It appears to use the same POs gen'd by xgettext if that's what you
> >>are asking about.
> >>
> >>
> >>
> >>>4) If setVar is not done on a variable then I'm thinking what will
happen
> >>>
> >>>
> >is
> >
> >
> >>>the variable name with $ will appear instead of the variable's value.
> >>>
> >>>
> >This
> >
> >
> >>>could get easily missed by various people at various times.
> >>>
> >>>5) How stable and used is this class?
> >>>
> >>>
> >>>
> >>>
> >>They use it and claim it is stable enough for their use. We will have to
> >>test it/read docs to determine it's how it functions when mis-used.
> >>
> >>The main point here, though, is that I haven't seen a more simple way to
> >>get things fully translated (as opposed to in pieces) than a wrapper
> >>like this or through complicated (s)printfs. If others think the pieced
> >>together translations will suffice, then so be it. I just would hate to
> >>have gone through this trouble and find later that people really can't
> >>stand the translations that have been done and to realize that with a
> >>little extra work at the beginning they could have been better.
> >>
> >>jesse
> >>
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>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
> >
> >
>
>
>
> -------------------------------------------------------
> 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
>

Re: [Web-erp-developers] file imports for serial items

[Jesse P. <je...@st...>]

I'd have to say it happens more than rarely. Again, my big worry is 
choppy, nonsensical  translations putting off potential users. I also 
believe that using a wrapper class, including the one I mentioned, would 
allow us to *only* use it when necessary and the _('xxx') to be used 
every other time.
Maybe we need to get some people doing or that can do translations to 
take a look and see what effect it may have. It's just something that 
would be nice to get right the first time since there are well over 150 
scripts that have to follow which ever way we determine as best.

jesse


Daintrees wrote:

>Yes this is a good thought.
>
>The saving grace is that variables are very rarely used inside strings.
>Perhaps I am lazy, but I really don't see the need to go to great lengths
>for the 2 or 3 instances of where this happens.
>
>The fall back where gettext is not installed on the local server is to
>create a function that just returns the english string. Translated
>environments thus need gettext installed. I understand that gettext is
>pretty widely available on most web-hosts. It is widely used and tested in
>many environments. I am keen to stick with tried and true.
>
>Phil
>
>----- Original Message ----- 
>From: "Jesse Peterson" <je...@st...>
>To: <web...@li...>
>Sent: Monday, September 06, 2004 9:18 AM
>Subject: Re: [Web-erp-developers] file imports for serial items
>
>
>  
>
>>>Pros
>>>1) We would need to evaluate how much further it gets the translation
>>>compared to not using.
>>>
>>>
>>>      
>>>
>>I see it as allowing more accurate string/message translations however
>>it will require a little more code for the developers and a little extra
>>instruction to a translator (how to move around variables).
>>
>>    
>>
>>>Cons
>>>1) The possible slowdowns of using the class instead of built in php
>>>processor gettext code
>>>
>>>
>>>      
>>>
>>This class allows use of php's built-in gettext libraries if they are
>>available. This is important as I am pretty sure we could inter-mix it's
>>use with the standard gettext function, therefor only having to use it
>>when we needed a string with vars in it.
>>
>>    
>>
>>>2) What's with the setVar?  Does that mean we need to add setVars for
>>>      
>>>
>every
>  
>
>>>var used in a string? That will be some more work.
>>>
>>>
>>>
>>>      
>>>
>>Yes, and yes it will be a little more work.
>>
>>    
>>
>>>3) Do the tolls for making the po's such as xgettext all work smoothly
>>>      
>>>
>with
>  
>
>>>this enhancement?
>>>
>>>
>>>      
>>>
>>huh? It appears to use the same POs gen'd by xgettext if that's what you
>>are asking about.
>>
>>    
>>
>>>4) If setVar is not done on a variable then I'm thinking what will happen
>>>      
>>>
>is
>  
>
>>>the variable name with $ will appear instead of the variable's value.
>>>      
>>>
>This
>  
>
>>>could get easily missed by various people at various times.
>>>
>>>5) How stable and used is this class?
>>>
>>>
>>>      
>>>
>>They use it and claim it is stable enough for their use. We will have to
>>test it/read docs to determine it's how it functions when mis-used.
>>
>>The main point here, though, is that I haven't seen a more simple way to
>>get things fully translated (as opposed to in pieces) than a wrapper
>>like this or through complicated (s)printfs. If others think the pieced
>>together translations will suffice, then so be it. I just would hate to
>>have gone through this trouble and find later that people really can't
>>stand the translations that have been done and to realize that with a
>>little extra work at the beginning they could have been better.
>>
>>jesse
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>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
>  
>