Menu
▾
▴
web-erp-developers
|
From: Daintrees <p.d...@pa...> - 2004-08-02 20:20:08
|
Luca, I am not sure if you have joined the developers list, but I have forw= areded this email to them because I would like to run your proposal past the= other interested and knowledgeable folk - hope you dont mind! We have a table of each script - that was added in 2.9 for the contex= t sensitive help (currently not language specific) - each script is giv= en a unique id - this may also be helpful for security Steve - the idea of retrieving just the labels for the script being run is appealing as i= s having a user interface for translators that doesnt involve editing f= iles. You have some good points. The best point of all - you are prepared t= o do a lot of work for the project - most appreciated. Lets just see if there are any other opinions/pitfalls that the rest = of the team see - so we dont trip and fall on this. Phil ----- Original Message -----=20 =46rom: "ing. Luca Turlon Don=E0" <luc...@pd...> To: "Phil Daintree" <p.d...@pa...> Sent: Tuesday, August 03, 2004 12:11 AM Subject: Re: Italian Translation of web-erp > Hi Phil. > I've been reading thru your mail several times before answering, ca= use wanted > to be sure to understand every single issue ou pointed out. > > The main consideration that comes out is that your approach is very similar to > mine, i.e.: > -You are proposing a function call, I am proposing to use an array = with a > literal index. > -You are proposing several files with the translation, i am proposi= ng several > groups of rows in a table. > > Firts let me explain one thing: my idea consists in loading an arra= y from the > db, i.e.: in the beginning of every page I make a bulk load of all = the labels > in the language that has to be shown. So we do not have a full read= cycle > (connect-query-parse the query, disconnect) on the db for every sin= gle label > in the page. We read everything at the beginning, load it in the la= ng array > and then use the lang array. This should address the second concern= that you > put in your email. There is another thing: if we add a column on th= e db table, > containing the script (or an unique code which identifies the scrip= t) that is > going to be rendered we can achieve two more thing: first we can lo= ad just the > labels used in that script, reducing the size of the array. Secondl= y we will > have a documentation of what is shown in every page. > > Regarding the other concern, i.e. the smallness of 30 chars for a l= abel > identifier, I believe that i could enlarge that column to a wider s= tring: i do > not see any problem on this. > > The last thing you say, that is the code should be easy understanda= ble. Maybe > you're right in considering the code easier to read having a full e= nglish > label, but I think that a label identifier with some comment could = do the > same. In this way you could avoid the problem you mentioned about c= hanges in > the english labels. > > Please now let me tell some other things about the "function" appro= ach: > a) there is no other way than creating a php script to translate th= e > application. With the db approach I could create a page to let any = kind of > user (not only a PHP programmer) manage the translation > b) it can become tough managing any new version of the system: with= the db you > can query and see how many entries you have for each language, and = you can > easily identify which labels has to be translated. With the include= d file > approach you have to work on the files, hoping that every file is w= ritten with > exactly the same approach. > c) Since you must delegate people to translate (unless you know at = least 15 > languages) you can loose control on the code: what if a russian sen= ds you an > email saying that the system not working, just because the russian translator > forgot a ";" in his code? With the db approach the worst thing that= could > happen is a wrong translation or something written in English, but = not > something that halts the system. > d) With the db you have a sort of documentation, which can help in creating > help files... > e) it is at any time possible to automatically generate any languag= e script, > i.e a language/italiano.php can be generated from the db and we can= switch to > your "function" approach. > f) ther is another thing regarding the usage of the entire english = label as a > parameter: imagine if you forget to put the function call. With the= label > identifier you immediately see that there is something difficult to= read on > the page. With the full english label you may even not notice the e= rror. > > > Finally: I do believe that the language variable should be kept, in= the > future, in the session of the user, having each user working with h= is/her own > language. For now I am just using a default language, but in the fu= ture it can > be changed. > > One very last thing: I have to work on it, 'cause these friends of = mine needs > it, and I will work on the application making it multilanguage. I w= ill go thru > the entire application, populating the db tables and changing the = scripts > where needed. After I will finish my job, I believe by the end of september, I > am going to send you the result of my job: thus you'll get a finish= ed a work, > and you'd be not worried by having something not finished. The only= thing is > to understand what has changed from noew (or better from the 2.9 re= lease of > the system) till the end of september. > > Luca > > Scrive Phil Daintree <p.d...@pa...>: > > > Hi Luca, > > > > There has been quite a bit of a discussion about multi-language -= there > > are a lot of issues. Maybe I scare too easily, but it seems like = a > > massive undertaking :-O > > > > Thanks so much for considering what is really quite a sizable pro= ject > > here. The other fear factor in taking this sort of thing on is if= we > > start it I am the muggins that has a stuffed system if we can't f= inish > > it. It sure would be great to make web-erp multi-language. > > > > I see the way you are heading with what you started .... my over-= riding > > and BIG worry in going to multi-language is that the code might b= ecome > > more difficult to make sense of (of course it being in English mu= st be > > quite a snag for those who use another language anyway). Under th= e > > scenario you are proposing we would, I guess have a varchar(30) > > description for the label that would be substituted by the TEXT f= ield. > > There a couple of reasons why I'm not that keen on this approach: > > > > 1. 30 characters isn't much to describe the text variable. The fu= ll > > context that the label provides I think significantly improves th= e > > ability to understand code. > > 2. If this requires a query for every label then this could be qu= ite an > > overhead on the db and a potential delay for the user. (all users= ). > > > > Of the approaches discussed in the developers list - there is an = archive > > of this http://sourceforge.net/mailarchive/forum.php?forum_id= =3D34088 > > > > I prefer Steve Kaill's approach and the approach used in open-acc= ounting > > ie enclosing the the full label in a function call eg. > > > > echo language("This is how I rekon we should do multi-language so= the > > code remains relatively easy to read"); > > > > the language function returns the language string required by the= user. > > > > We hold a $_SESSION['language'] variable which is stored in the > > www_users table and retreived at the time of login. > > > > This language variable would be the same name as the file to incl= ude > > under a new languages directory. > > > > The function language would be in this include directory. > > > > The function language then takes the text of the english label as= a > > parameter - the $SESSION['language'] is defined as global inside = this > > function and returns the the language string appropriate - if the= re is > > no match for the string parameter passed then the parameter ie th= e > > english label is returned. > > > > The english language function in languages/english.php would just= return > > the parameter itself. > > > > I have not gone down the track of considering if the label substi= tution > > is done using an array or what .... I would probably take a look = at > > open-accounting logic. > > > > This approach does retain a critical requirement for webERP ie th= at of > > easily understandable code. > > > > All approaches have their down side - > > > > 1. This puts the overhead on the web-server/ php interpreter. How= ever, > > this is pretty fast.However,potentially significant memory is req= uired - > > for what I have tried desperately to be minimalist in terms of re= sources > > required to run it. > > > > 2. Anyone changing the english labels will stuff up the translati= on file > > ie the include file of strings in english with the equivalent lan= guage > > string! > > > > Do you see any other snags with this approach Luca? > > Could you consider a slightly different approach? > > > > Phil > > > > > > On Fri, 2004-07-30 at 17:12, ing. Luca Tur=3D?ISO-8859-1?Q?lon_Do= n=3DE0?=3D > > wrote: > > > Hello Phil, > > > I've started to work on it. > > > Here is how I want to address the issue. > > > First I am going to create a table containing all the labels > > > > > > CREATE TABLE `languages` ( > > > `id` bigint(20) NOT NULL auto_increment, > > > `LANGID` varchar(15) NOT NULL default '', > > > `TEXTID` varchar(30) NOT NULL default '', > > > `TEXT` varchar(255) NOT NULL default '', > > > UNIQUE KEY `id` (`id`) > > > ) TYPE=3DInnoDB COMMENT=3D'Table containing labels to be showed= on the > > pages'; > > > > > > (I don't think InnoDB is necessary for this table, since it is = only > > read by > > > normal users, and loaded by installer: i kept that type only fo= r > > compatibility > > > with your design). > > > > > > TEXTID is a code that identifies a specific label in very page.= With > > some work > > > we can undertsand if the same label is going to be used on diff= rent > > pages. > > > TEXT is the text that is going to appear on the browser. > > > > > > On the config.php file I've inserted another variable: > > > $DefaultLanguage=3D"ITALIANO"; //of course you can put ENGLISH > > > > > > In session.inc i've inserted this line > > > include ("language.php"); > > > just after > > > include("includes/ConnectDB.inc"); > > > > > > As you can see in the attachment, language.php loads an array n= amed > > $lang with > > > the contents of the table "languages". > > > By default it loads the $DefaultLanguage, but if the variable i= s not > > defined it > > > loads the English table. > > > > > > Then I simply substitute all the labels around the php and html= code > > with the > > > corresponding entry in the $lang array. > > > As an example you can see in the attached login.php file the fo= llowing > > lines: 9, > > > 53, 57, 66. > > > > > > Having the labels in a db table can lead to another enhancement= : every > > user can > > > choose his/her own language. This could be useful for companies= having > > clients > > > spreaded around various countries.... > > > > > > What do you think about? > > > Can we arrange my small improvement with the future developemen= t you > > are making > > > in web-erp? > > > > > > Luca > > > > > > > > > Scrive Phil Daintree <p.d...@pa...>: > > > > > > > There has been some discussion about multi-language recently = on the > > > > list. > > > > > > > > I am prepared to maintain a rigorous log of changes to script= s. > > Perhaps > > > > I could produce a diff file for all changes on each release b= ut you > > > > would have to apply these changes to the italian version. I h= ave had > > a > > > > similar request from a spanish speaking person. > > > > > > > > An Italian version would be good. > > > > > > > > web-erp is not ideally suited to multi-language as you point = out > > since > > > > all labels, print and echo statements would need to be modifi= ed and > > > > changes in the core scripts would need to be applied to each > > language's > > > > scripts manually. > > > > > > > > Phil > > > > > > > > > > > > On Thu, 2004-07-29 at 17:28, ing. Luca > > Tur=3D?ISO-8859-1?Q?lon_Don=3DE0?=3D > > > > wrote: > > > > > Dear Phil, > > > > > a couple of friends, who ar starting up a new fashion compa= ny here > > in > > > > italy, > > > > > are very interested in using the application you developed. > > > > > > > > > > Since they're not very acquainted with the english language= and > > > > jargon, i need > > > > > to translate the application for them. > > > > > > > > > > I have various ways to do this: one is to simply browse the= code > > and > > > > change > > > > > all the labels into italian. Doing so, i am very concerned = about > > > > everytime you > > > > > give a new release: at that time I have to check every chan= ge in > > every > > > > single > > > > > file. > > > > > The other one is to modify the code in order to have a sepa= rate > > place > > > > in which > > > > > labels and all the language-dependent stuff are stored. Thi= s can > > be a > > > > DB table > > > > > or a file... i still don't know. > > > > > Before starting this, i need to know a couple of things: > > > > > First: are you going to do what I would like to do? In this= case > > when > > > > do you > > > > > think you will release a multilingual version of web-erp? A= nd: do > > you > > > > need any > > > > > help? I'd be happy to help in any way. > > > > > Second: if you're not going to do the multilingual version,= can I > > work > > > > on it? > > > > > Can we synch our two different tracks (the improvement of t= he > > system > > > > that > > > > > maybe you are doing and my translation-multilingual effort)= ? > > > > > > > > > > Please give me an answer on this, since i am strongly spons= oring > > your > > > > > product... > > > > > Best Regards, > > > > > Luca > > > > > > > > > > PS: I am working on the translation of the manual. When fin= ished, > > I'll > > > > send it > > > > > to you. > > > > > > > > > > > > |
|
From: skaill <sk...@ro...> - 2004-08-02 22:00:50
|
This is an area that we will need to work on as well. If Luca wants to "get together" at some point to work on this I am available. I would point out to Luca that keeping the original English strings in the code instead of using an identifier keeps the code WAY more readable. That's my opinion after having worked extensively with a product that did it with identifiers. Code is scary to read when it has identifiers instead of literals. Many will be thrown off by doing that. I have recently discovered a function in PHP called gettext which may be for exactly what we are trying to do. I don't know enough about it but before doing our own coding for Multilanguage it would be nice to see if the built in gettext functionality will do it. Just guessing but I think loading the entire language file at the beginning of each page may be much slower than doing a few reads within one page. A few lines versus hundreds to thousands. Plus the memory for each user would be way more. Here's an idea that actually ends up a modified version of Luca's suggestion to keep the page number in the db. Have an array of strings at the top of each page where those strings are the strings used within the page. Call a language function that retrieves and returns all of these at the page beginning. When language(...) is called within the page, it first looks to see if the string was looked up already and uses that otherwise goes out to retrieve from the db, file or wherever. This will minimize the amount needing to be looked up yet look it up (or most of it) all at once as Luca is suggesting. We can build in whatever is changed until September very easily. It's just important to know which version Luca started on. I agree that db storage is the best for the Multilanguage information over another way such as file. Steve ----- Original Message ----- From: "Daintrees" <p.d...@pa...> To: <web...@li...> Cc: <luc...@pd...> Sent: Monday, August 02, 2004 4:21 PM Subject: [Web-erp-developers] Fw: Italian Translation of web-erp Luca, I am not sure if you have joined the developers list, but I have forwareded this email to them because I would like to run your proposal past the other interested and knowledgeable folk - hope you dont mind! We have a table of each script - that was added in 2.9 for the context sensitive help (currently not language specific) - each script is given a unique id - this may also be helpful for security Steve - the idea of retrieving just the labels for the script being run is appealing as is having a user interface for translators that doesnt involve editing files. You have some good points. The best point of all - you are prepared to do a lot of work for the project - most appreciated. Lets just see if there are any other opinions/pitfalls that the rest of the team see - so we dont trip and fall on this. Phil ----- Original Message ----- From: "ing. Luca Turlon Donà" <luc...@pd...> To: "Phil Daintree" <p.d...@pa...> Sent: Tuesday, August 03, 2004 12:11 AM Subject: Re: Italian Translation of web-erp > Hi Phil. > I've been reading thru your mail several times before answering, cause wanted > to be sure to understand every single issue ou pointed out. > > The main consideration that comes out is that your approach is very similar to > mine, i.e.: > -You are proposing a function call, I am proposing to use an array with a > literal index. > -You are proposing several files with the translation, i am proposing several > groups of rows in a table. > > Firts let me explain one thing: my idea consists in loading an array from the > db, i.e.: in the beginning of every page I make a bulk load of all the labels > in the language that has to be shown. So we do not have a full read cycle > (connect-query-parse the query, disconnect) on the db for every single label > in the page. We read everything at the beginning, load it in the lang array > and then use the lang array. This should address the second concern that you > put in your email. There is another thing: if we add a column on the db table, > containing the script (or an unique code which identifies the script) that is > going to be rendered we can achieve two more thing: first we can load just the > labels used in that script, reducing the size of the array. Secondly we will > have a documentation of what is shown in every page. > > Regarding the other concern, i.e. the smallness of 30 chars for a label > identifier, I believe that i could enlarge that column to a wider string: i do > not see any problem on this. > > The last thing you say, that is the code should be easy understandable. Maybe > you're right in considering the code easier to read having a full english > label, but I think that a label identifier with some comment could do the > same. In this way you could avoid the problem you mentioned about changes in > the english labels. > > Please now let me tell some other things about the "function" approach: > a) there is no other way than creating a php script to translate the > application. With the db approach I could create a page to let any kind of > user (not only a PHP programmer) manage the translation > b) it can become tough managing any new version of the system: with the db you > can query and see how many entries you have for each language, and you can > easily identify which labels has to be translated. With the included file > approach you have to work on the files, hoping that every file is written with > exactly the same approach. > c) Since you must delegate people to translate (unless you know at least 15 > languages) you can loose control on the code: what if a russian sends you an > email saying that the system not working, just because the russian translator > forgot a ";" in his code? With the db approach the worst thing that could > happen is a wrong translation or something written in English, but not > something that halts the system. > d) With the db you have a sort of documentation, which can help in creating > help files... > e) it is at any time possible to automatically generate any language script, > i.e a language/italiano.php can be generated from the db and we can switch to > your "function" approach. > f) ther is another thing regarding the usage of the entire english label as a > parameter: imagine if you forget to put the function call. With the label > identifier you immediately see that there is something difficult to read on > the page. With the full english label you may even not notice the error. > > > Finally: I do believe that the language variable should be kept, in the > future, in the session of the user, having each user working with his/her own > language. For now I am just using a default language, but in the future it can > be changed. > > One very last thing: I have to work on it, 'cause these friends of mine needs > it, and I will work on the application making it multilanguage. I will go thru > the entire application, populating the db tables and changing the scripts > where needed. After I will finish my job, I believe by the end of september, I > am going to send you the result of my job: thus you'll get a finished a work, > and you'd be not worried by having something not finished. The only thing is > to understand what has changed from noew (or better from the 2.9 release of > the system) till the end of september. > > Luca > > Scrive Phil Daintree <p.d...@pa...>: > > > Hi Luca, > > > > There has been quite a bit of a discussion about multi-language - there > > are a lot of issues. Maybe I scare too easily, but it seems like a > > massive undertaking :-O > > > > Thanks so much for considering what is really quite a sizable project > > here. The other fear factor in taking this sort of thing on is if we > > start it I am the muggins that has a stuffed system if we can't finish > > it. It sure would be great to make web-erp multi-language. > > > > I see the way you are heading with what you started .... my over-riding > > and BIG worry in going to multi-language is that the code might become > > more difficult to make sense of (of course it being in English must be > > quite a snag for those who use another language anyway). Under the > > scenario you are proposing we would, I guess have a varchar(30) > > description for the label that would be substituted by the TEXT field. > > There a couple of reasons why I'm not that keen on this approach: > > > > 1. 30 characters isn't much to describe the text variable. The full > > context that the label provides I think significantly improves the > > ability to understand code. > > 2. If this requires a query for every label then this could be quite an > > overhead on the db and a potential delay for the user. (all users). > > > > Of the approaches discussed in the developers list - there is an archive > > of this http://sourceforge.net/mailarchive/forum.php?forum_id=34088 > > > > I prefer Steve Kaill's approach and the approach used in open-accounting > > ie enclosing the the full label in a function call eg. > > > > echo language("This is how I rekon we should do multi-language so the > > code remains relatively easy to read"); > > > > the language function returns the language string required by the user. > > > > We hold a $_SESSION['language'] variable which is stored in the > > www_users table and retreived at the time of login. > > > > This language variable would be the same name as the file to include > > under a new languages directory. > > > > The function language would be in this include directory. > > > > The function language then takes the text of the english label as a > > parameter - the $SESSION['language'] is defined as global inside this > > function and returns the the language string appropriate - if there is > > no match for the string parameter passed then the parameter ie the > > english label is returned. > > > > The english language function in languages/english.php would just return > > the parameter itself. > > > > I have not gone down the track of considering if the label substitution > > is done using an array or what .... I would probably take a look at > > open-accounting logic. > > > > This approach does retain a critical requirement for webERP ie that of > > easily understandable code. > > > > All approaches have their down side - > > > > 1. This puts the overhead on the web-server/ php interpreter. However, > > this is pretty fast.However,potentially significant memory is required - > > for what I have tried desperately to be minimalist in terms of resources > > required to run it. > > > > 2. Anyone changing the english labels will stuff up the translation file > > ie the include file of strings in english with the equivalent language > > string! > > > > Do you see any other snags with this approach Luca? > > Could you consider a slightly different approach? > > > > Phil > > > > > > On Fri, 2004-07-30 at 17:12, ing. Luca Tur=?ISO-8859-1?Q?lon_Don=E0?= > > wrote: > > > Hello Phil, > > > I've started to work on it. > > > Here is how I want to address the issue. > > > First I am going to create a table containing all the labels > > > > > > CREATE TABLE `languages` ( > > > `id` bigint(20) NOT NULL auto_increment, > > > `LANGID` varchar(15) NOT NULL default '', > > > `TEXTID` varchar(30) NOT NULL default '', > > > `TEXT` varchar(255) NOT NULL default '', > > > UNIQUE KEY `id` (`id`) > > > ) TYPE=InnoDB COMMENT='Table containing labels to be showed on the > > pages'; > > > > > > (I don't think InnoDB is necessary for this table, since it is only > > read by > > > normal users, and loaded by installer: i kept that type only for > > compatibility > > > with your design). > > > > > > TEXTID is a code that identifies a specific label in very page. With > > some work > > > we can undertsand if the same label is going to be used on diffrent > > pages. > > > TEXT is the text that is going to appear on the browser. > > > > > > On the config.php file I've inserted another variable: > > > $DefaultLanguage="ITALIANO"; //of course you can put ENGLISH > > > > > > In session.inc i've inserted this line > > > include ("language.php"); > > > just after > > > include("includes/ConnectDB.inc"); > > > > > > As you can see in the attachment, language.php loads an array named > > $lang with > > > the contents of the table "languages". > > > By default it loads the $DefaultLanguage, but if the variable is not > > defined it > > > loads the English table. > > > > > > Then I simply substitute all the labels around the php and html code > > with the > > > corresponding entry in the $lang array. > > > As an example you can see in the attached login.php file the following > > lines: 9, > > > 53, 57, 66. > > > > > > Having the labels in a db table can lead to another enhancement: every > > user can > > > choose his/her own language. This could be useful for companies having > > clients > > > spreaded around various countries.... > > > > > > What do you think about? > > > Can we arrange my small improvement with the future developement you > > are making > > > in web-erp? > > > > > > Luca > > > > > > > > > Scrive Phil Daintree <p.d...@pa...>: > > > > > > > There has been some discussion about multi-language recently on the > > > > list. > > > > > > > > I am prepared to maintain a rigorous log of changes to scripts. > > Perhaps > > > > I could produce a diff file for all changes on each release but you > > > > would have to apply these changes to the italian version. I have had > > a > > > > similar request from a spanish speaking person. > > > > > > > > An Italian version would be good. > > > > > > > > web-erp is not ideally suited to multi-language as you point out > > since > > > > all labels, print and echo statements would need to be modified and > > > > changes in the core scripts would need to be applied to each > > language's > > > > scripts manually. > > > > > > > > Phil > > > > > > > > > > > > On Thu, 2004-07-29 at 17:28, ing. Luca > > Tur=?ISO-8859-1?Q?lon_Don=E0?= > > > > wrote: > > > > > Dear Phil, > > > > > a couple of friends, who ar starting up a new fashion company here > > in > > > > italy, > > > > > are very interested in using the application you developed. > > > > > > > > > > Since they're not very acquainted with the english language and > > > > jargon, i need > > > > > to translate the application for them. > > > > > > > > > > I have various ways to do this: one is to simply browse the code > > and > > > > change > > > > > all the labels into italian. Doing so, i am very concerned about > > > > everytime you > > > > > give a new release: at that time I have to check every change in > > every > > > > single > > > > > file. > > > > > The other one is to modify the code in order to have a separate > > place > > > > in which > > > > > labels and all the language-dependent stuff are stored. This can > > be a > > > > DB table > > > > > or a file... i still don't know. > > > > > Before starting this, i need to know a couple of things: > > > > > First: are you going to do what I would like to do? In this case > > when > > > > do you > > > > > think you will release a multilingual version of web-erp? And: do > > you > > > > need any > > > > > help? I'd be happy to help in any way. > > > > > Second: if you're not going to do the multilingual version, can I > > work > > > > on it? > > > > > Can we synch our two different tracks (the improvement of the > > system > > > > that > > > > > maybe you are doing and my translation-multilingual effort)? > > > > > > > > > > Please give me an answer on this, since i am strongly sponsoring > > your > > > > > product... > > > > > Best Regards, > > > > > Luca > > > > > > > > > > PS: I am working on the translation of the manual. When finished, > > I'll > > > > send it > > > > > to you. > > > > > > > > > > > > ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Web-erp-developers mailing list Web...@li... https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Stins, D. <DR...@Zi...> - 2004-08-03 08:16:32
|
I agree that it would a risk not to use existing knowledge implemented in gnu gettext. Or is gnu gettext overdone for web-erp? see below. Dick ----- Original Message ----- From: "skaill" <sk...@ro...> To: <web...@li...> Sent: Tuesday, August 03, 2004 12:01 AM Subject: Re: [Web-erp-developers] Fw: Italian Translation of web-erp > This is an area that we will need to work on as well. If Luca wants to"get > together" at some point to work on this I am available. > > I would point out to Luca that keeping the original English strings in = the > code instead of using an identifier keeps the code WAY more readable. > That's my opinion after having worked extensively with a product that d= id it > with identifiers. Code is scary to read when it has identifiers instea= d of > literals. Many will be thrown off by doing that. > > I have recently discovered a function in PHP called gettext which may b= e for > exactly what we are trying to do. I don't know enough about it but bef= ore > doing our own coding for Multilanguage it would be nice to see if the built > in gettext functionality will do it. > > Just guessing but I think loading the entire language file at the beginning > of each page may be much slower than doing a few reads within one page.= A normally is one database read faster than several database reads. Since every database read does need to do extra parsing which used to be timeconsuming. > few lines versus hundreds to thousands. Plus the memory for each user would > be way more. Here's an idea that actually ends up a modified version o= f I guess there will be about 700 translation strings with avarage length o= f 10. This is 7000 bytes. So when you plug in 256mb extra ram, you can support 256mb/7000bytes =3D 38347 users :) > Luca's suggestion to keep the page number in the db. Have an array of > strings at the top of each page where those strings are the strings use= d > within the page. Call a language function that retrieves and returns a= ll of > these at the page beginning. When language(...) is called within the page, > it first looks to see if the string was looked up already and uses that > otherwise goes out to retrieve from the db, file or wherever. This wil= l > minimize the amount needing to be looked up yet look it up (or most of = it) > all at once as Luca is suggesting. > > We can build in whatever is changed until September very easily. It's just > important to know which version Luca started on. > > I agree that db storage is the best for the Multilanguage information o= ver > another way such as file. > > Steve > > ----- Original Message ----- > From: "Daintrees" <p.d...@pa...> > To: <web...@li...> > Cc: <luc...@pd...> > Sent: Monday, August 02, 2004 4:21 PM > Subject: [Web-erp-developers] Fw: Italian Translation of web-erp > > > Luca, > > I am not sure if you have joined the developers list, but I have forwareded > this email to them because I would like to run your proposal past the other > interested and knowledgeable folk - hope you dont mind! > > We have a table of each script - that was added in 2.9 for the context > sensitive help (currently not language specific) - each script is given= a > unique id - this may also be helpful for security Steve - the idea of > retrieving just the labels for the script being run is appealing as is > having a user interface for translators that doesnt involve editing fil= es. > You have some good points. The best point of all - you are prepared to = do a > lot of work for the project - most appreciated. > > Lets just see if there are any other opinions/pitfalls that the rest of the > team see - so we dont trip and fall on this. > > Phil > > ----- Original Message ----- > From: "ing. Luca Turlon Don=E0" <luc...@pd...> > To: "Phil Daintree" <p.d...@pa...> > Sent: Tuesday, August 03, 2004 12:11 AM > Subject: Re: Italian Translation of web-erp > > > > Hi Phil. > > I've been reading thru your mail several times before answering, caus= e > wanted > > to be sure to understand every single issue ou pointed out. > > > > The main consideration that comes out is that your approach is very > similar to > > mine, i.e.: > > -You are proposing a function call, I am proposing to use an array wi= th a > > literal index. > > -You are proposing several files with the translation, i am proposing > several > > groups of rows in a table. > > > > Firts let me explain one thing: my idea consists in loading an array from > the > > db, i.e.: in the beginning of every page I make a bulk load of all th= e > labels > > in the language that has to be shown. So we do not have a full read cycle > > (connect-query-parse the query, disconnect) on the db for every singl= e > label > > in the page. We read everything at the beginning, load it in the lang > array > > and then use the lang array. This should address the second concern t= hat > you > > put in your email. There is another thing: if we add a column on the = db > table, > > containing the script (or an unique code which identifies the script) that > is > > going to be rendered we can achieve two more thing: first we can load just > the > > labels used in that script, reducing the size of the array. Secondly = we > will > > have a documentation of what is shown in every page. > > > > Regarding the other concern, i.e. the smallness of 30 chars for a lab= el > > identifier, I believe that i could enlarge that column to a wider string: > i do > > not see any problem on this. > > > > The last thing you say, that is the code should be easy understandabl= e. > Maybe > > you're right in considering the code easier to read having a full english > > label, but I think that a label identifier with some comment could do the > > same. In this way you could avoid the problem you mentioned about changes > in > > the english labels. > > > > Please now let me tell some other things about the "function" approac= h: > > a) there is no other way than creating a php script to translate the > > application. With the db approach I could create a page to let any ki= nd of > > user (not only a PHP programmer) manage the translation > > b) it can become tough managing any new version of the system: with t= he db > you > > can query and see how many entries you have for each language, and yo= u can > > easily identify which labels has to be translated. With the included file > > approach you have to work on the files, hoping that every file is written > with > > exactly the same approach. > > c) Since you must delegate people to translate (unless you know at le= ast > 15 > > languages) you can loose control on the code: what if a russian sends you > an > > email saying that the system not working, just because the russian > translator > > forgot a ";" in his code? With the db approach the worst thing that could > > happen is a wrong translation or something written in English, but no= t > > something that halts the system. > > d) With the db you have a sort of documentation, which can help in > creating > > help files... > > e) it is at any time possible to automatically generate any language > script, > > i.e a language/italiano.php can be generated from the db and we can switch > to > > your "function" approach. > > f) ther is another thing regarding the usage of the entire english la= bel > as a > > parameter: imagine if you forget to put the function call. With the label > > identifier you immediately see that there is something difficult to r= ead > on > > the page. With the full english label you may even not notice the err= or. > > > > > > Finally: I do believe that the language variable should be kept, in t= he > > future, in the session of the user, having each user working with his/her > own > > language. For now I am just using a default language, but in the futu= re it > can > > be changed. > > > > One very last thing: I have to work on it, 'cause these friends of mi= ne > needs > > it, and I will work on the application making it multilanguage. I wil= l go > thru > > the entire application, populating the db tables and changing the scripts > > where needed. After I will finish my job, I believe by the end of > september, I > > am going to send you the result of my job: thus you'll get a finished= a > work, > > and you'd be not worried by having something not finished. The only thing > is > > to understand what has changed from noew (or better from the 2.9 rele= ase > of > > the system) till the end of september. > > > > Luca > > > > Scrive Phil Daintree <p.d...@pa...>: > > > > > Hi Luca, > > > > > > There has been quite a bit of a discussion about multi-language - there > > > are a lot of issues. Maybe I scare too easily, but it seems like a > > > massive undertaking :-O > > > > > > Thanks so much for considering what is really quite a sizable proje= ct > > > here. The other fear factor in taking this sort of thing on is if w= e > > > start it I am the muggins that has a stuffed system if we can't fin= ish > > > it. It sure would be great to make web-erp multi-language. > > > > > > I see the way you are heading with what you started .... my over-riding > > > and BIG worry in going to multi-language is that the code might bec= ome > > > more difficult to make sense of (of course it being in English must= be > > > quite a snag for those who use another language anyway). Under the > > > scenario you are proposing we would, I guess have a varchar(30) > > > description for the label that would be substituted by the TEXT fie= ld. > > > There a couple of reasons why I'm not that keen on this approach: > > > > > > 1. 30 characters isn't much to describe the text variable. The full > > > context that the label provides I think significantly improves the > > > ability to understand code. > > > 2. If this requires a query for every label then this could be quit= e an > > > overhead on the db and a potential delay for the user. (all users). > > > > > > Of the approaches discussed in the developers list - there is an archive > > > of this http://sourceforge.net/mailarchive/forum.php?forum_id=3D340= 88 > > > > > > I prefer Steve Kaill's approach and the approach used in open-accounting > > > ie enclosing the the full label in a function call eg. > > > > > > echo language("This is how I rekon we should do multi-language so t= he > > > code remains relatively easy to read"); > > > > > > the language function returns the language string required by the user. > > > > > > We hold a $_SESSION['language'] variable which is stored in the > > > www_users table and retreived at the time of login. > > > > > > This language variable would be the same name as the file to includ= e > > > under a new languages directory. > > > > > > The function language would be in this include directory. > > > > > > The function language then takes the text of the english label as a > > > parameter - the $SESSION['language'] is defined as global inside th= is > > > function and returns the the language string appropriate - if there= is > > > no match for the string parameter passed then the parameter ie the > > > english label is returned. > > > > > > The english language function in languages/english.php would just return > > > the parameter itself. > > > > > > I have not gone down the track of considering if the label substitution > > > is done using an array or what .... I would probably take a look at > > > open-accounting logic. > > > > > > This approach does retain a critical requirement for webERP ie that= of > > > easily understandable code. > > > > > > All approaches have their down side - > > > > > > 1. This puts the overhead on the web-server/ php interpreter. Howev= er, > > > this is pretty fast.However,potentially significant memory is required - > > > for what I have tried desperately to be minimalist in terms of resources > > > required to run it. > > > > > > 2. Anyone changing the english labels will stuff up the translation file > > > ie the include file of strings in english with the equivalent langu= age > > > string! > > > > > > Do you see any other snags with this approach Luca? > > > Could you consider a slightly different approach? > > > > > > Phil > > > > > > > > > On Fri, 2004-07-30 at 17:12, ing. Luca Tur=3D?ISO-8859-1?Q?lon_Don=3D= E0?=3D > > > wrote: > > > > Hello Phil, > > > > I've started to work on it. > > > > Here is how I want to address the issue. > > > > First I am going to create a table containing all the labels > > > > > > > > CREATE TABLE `languages` ( > > > > `id` bigint(20) NOT NULL auto_increment, > > > > `LANGID` varchar(15) NOT NULL default '', > > > > `TEXTID` varchar(30) NOT NULL default '', > > > > `TEXT` varchar(255) NOT NULL default '', > > > > UNIQUE KEY `id` (`id`) > > > > ) TYPE=3DInnoDB COMMENT=3D'Table containing labels to be showed o= n the > > > pages'; > > > > > > > > (I don't think InnoDB is necessary for this table, since it is on= ly > > > read by > > > > normal users, and loaded by installer: i kept that type only for > > > compatibility > > > > with your design). > > > > > > > > TEXTID is a code that identifies a specific label in very page. W= ith > > > some work > > > > we can undertsand if the same label is going to be used on diffre= nt > > > pages. > > > > TEXT is the text that is going to appear on the browser. > > > > > > > > On the config.php file I've inserted another variable: > > > > $DefaultLanguage=3D"ITALIANO"; //of course you can put ENGLISH > > > > > > > > In session.inc i've inserted this line > > > > include ("language.php"); > > > > just after > > > > include("includes/ConnectDB.inc"); > > > > > > > > As you can see in the attachment, language.php loads an array nam= ed > > > $lang with > > > > the contents of the table "languages". > > > > By default it loads the $DefaultLanguage, but if the variable is = not > > > defined it > > > > loads the English table. > > > > > > > > Then I simply substitute all the labels around the php and html c= ode > > > with the > > > > corresponding entry in the $lang array. > > > > As an example you can see in the attached login.php file the following > > > lines: 9, > > > > 53, 57, 66. > > > > > > > > Having the labels in a db table can lead to another enhancement: every > > > user can > > > > choose his/her own language. This could be useful for companies having > > > clients > > > > spreaded around various countries.... > > > > > > > > What do you think about? > > > > Can we arrange my small improvement with the future developement = you > > > are making > > > > in web-erp? > > > > > > > > Luca > > > > > > > > > > > > Scrive Phil Daintree <p.d...@pa...>: > > > > > > > > > There has been some discussion about multi-language recently on the > > > > > list. > > > > > > > > > > I am prepared to maintain a rigorous log of changes to scripts. > > > Perhaps > > > > > I could produce a diff file for all changes on each release but you > > > > > would have to apply these changes to the italian version. I hav= e had > > > a > > > > > similar request from a spanish speaking person. > > > > > > > > > > An Italian version would be good. > > > > > > > > > > web-erp is not ideally suited to multi-language as you point ou= t > > > since > > > > > all labels, print and echo statements would need to be modified and > > > > > changes in the core scripts would need to be applied to each > > > language's > > > > > scripts manually. > > > > > > > > > > Phil > > > > > > > > > > > > > > > On Thu, 2004-07-29 at 17:28, ing. Luca > > > Tur=3D?ISO-8859-1?Q?lon_Don=3DE0?=3D > > > > > wrote: > > > > > > Dear Phil, > > > > > > a couple of friends, who ar starting up a new fashion company here > > > in > > > > > italy, > > > > > > are very interested in using the application you developed. > > > > > > > > > > > > Since they're not very acquainted with the english language a= nd > > > > > jargon, i need > > > > > > to translate the application for them. > > > > > > > > > > > > I have various ways to do this: one is to simply browse the c= ode > > > and > > > > > change > > > > > > all the labels into italian. Doing so, i am very concerned ab= out > > > > > everytime you > > > > > > give a new release: at that time I have to check every change= in > > > every > > > > > single > > > > > > file. > > > > > > The other one is to modify the code in order to have a separa= te > > > place > > > > > in which > > > > > > labels and all the language-dependent stuff are stored. This = can > > > be a > > > > > DB table > > > > > > or a file... i still don't know. > > > > > > Before starting this, i need to know a couple of things: > > > > > > First: are you going to do what I would like to do? In this c= ase > > > when > > > > > do you > > > > > > think you will release a multilingual version of web-erp? And= : do > > > you > > > > > need any > > > > > > help? I'd be happy to help in any way. > > > > > > Second: if you're not going to do the multilingual version, c= an I > > > work > > > > > on it? > > > > > > Can we synch our two different tracks (the improvement of the > > > system > > > > > that > > > > > > maybe you are doing and my translation-multilingual effort)? > > > > > > > > > > > > Please give me an answer on this, since i am strongly sponsor= ing > > > your > > > > > > product... > > > > > > Best Regards, > > > > > > Luca > > > > > > > > > > > > PS: I am working on the translation of the manual. When finished, > > > I'll > > > > > send it > > > > > > to you. > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technolog= y > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technolog= y > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Stins, D. <DR...@Zi...> - 2004-08-02 22:06:35
|
Great that Luca would like to implement this functionality. When this solution does not what we expect, then we can always consider t= o try to create a generate script which generate a script to fill the array from the database which Luca is creating or generate some other better solution. Performance might vary per version of apache, linux, mysql, php and is no= t always logical. Like I read that read that session variables are always r= ead from disks (slow) and you might think that it is faster because you migh= t think that it you have tto load only once the translation array compared = to loading it for every page again (solution of Luca). When the loading of t= he array for every page is cached in RAM, then it's faster then loading once= in session variables. Luca: Let's see what happens! Success! With best regards, Dick Stins ----- Original Message ----- From: "Daintrees" <p.d...@pa...> To: <web...@li...> Cc: <luc...@pd...> Sent: Monday, August 02, 2004 10:21 PM Subject: [Web-erp-developers] Fw: Italian Translation of web-erp Luca, I am not sure if you have joined the developers list, but I have forwared= ed this email to them because I would like to run your proposal past the oth= er interested and knowledgeable folk - hope you dont mind! We have a table of each script - that was added in 2.9 for the context sensitive help (currently not language specific) - each script is given a unique id - this may also be helpful for security Steve - the idea of retrieving just the labels for the script being run is appealing as is having a user interface for translators that doesnt involve editing files= . You have some good points. The best point of all - you are prepared to do= a lot of work for the project - most appreciated. Lets just see if there are any other opinions/pitfalls that the rest of t= he team see - so we dont trip and fall on this. Phil ----- Original Message ----- From: "ing. Luca Turlon Don=E0" <luc...@pd...> To: "Phil Daintree" <p.d...@pa...> Sent: Tuesday, August 03, 2004 12:11 AM Subject: Re: Italian Translation of web-erp > Hi Phil. > I've been reading thru your mail several times before answering, cause wanted > to be sure to understand every single issue ou pointed out. > > The main consideration that comes out is that your approach is very similar to > mine, i.e.: > -You are proposing a function call, I am proposing to use an array with= a > literal index. > -You are proposing several files with the translation, i am proposing several > groups of rows in a table. > > Firts let me explain one thing: my idea consists in loading an array fr= om the > db, i.e.: in the beginning of every page I make a bulk load of all the labels > in the language that has to be shown. So we do not have a full read cyc= le > (connect-query-parse the query, disconnect) on the db for every single label > in the page. We read everything at the beginning, load it in the lang array > and then use the lang array. This should address the second concern tha= t you > put in your email. There is another thing: if we add a column on the db table, > containing the script (or an unique code which identifies the script) t= hat is > going to be rendered we can achieve two more thing: first we can load j= ust the > labels used in that script, reducing the size of the array. Secondly we will > have a documentation of what is shown in every page. > > Regarding the other concern, i.e. the smallness of 30 chars for a label > identifier, I believe that i could enlarge that column to a wider strin= g: i do > not see any problem on this. > > The last thing you say, that is the code should be easy understandable. Maybe > you're right in considering the code easier to read having a full engli= sh > label, but I think that a label identifier with some comment could do t= he > same. In this way you could avoid the problem you mentioned about chang= es in > the english labels. > > Please now let me tell some other things about the "function" approach: > a) there is no other way than creating a php script to translate the > application. With the db approach I could create a page to let any kind= of > user (not only a PHP programmer) manage the translation > b) it can become tough managing any new version of the system: with the= db you > can query and see how many entries you have for each language, and you = can > easily identify which labels has to be translated. With the included fi= le > approach you have to work on the files, hoping that every file is writt= en with > exactly the same approach. > c) Since you must delegate people to translate (unless you know at leas= t 15 > languages) you can loose control on the code: what if a russian sends y= ou an > email saying that the system not working, just because the russian translator > forgot a ";" in his code? With the db approach the worst thing that cou= ld > happen is a wrong translation or something written in English, but not > something that halts the system. > d) With the db you have a sort of documentation, which can help in creating > help files... > e) it is at any time possible to automatically generate any language script, > i.e a language/italiano.php can be generated from the db and we can swi= tch to > your "function" approach. > f) ther is another thing regarding the usage of the entire english labe= l as a > parameter: imagine if you forget to put the function call. With the lab= el > identifier you immediately see that there is something difficult to rea= d on > the page. With the full english label you may even not notice the error= . > > > Finally: I do believe that the language variable should be kept, in the > future, in the session of the user, having each user working with his/h= er own > language. For now I am just using a default language, but in the future= it can > be changed. > > One very last thing: I have to work on it, 'cause these friends of mine needs > it, and I will work on the application making it multilanguage. I will = go thru > the entire application, populating the db tables and changing the scri= pts > where needed. After I will finish my job, I believe by the end of september, I > am going to send you the result of my job: thus you'll get a finished a work, > and you'd be not worried by having something not finished. The only thi= ng is > to understand what has changed from noew (or better from the 2.9 releas= e of > the system) till the end of september. > > Luca > > Scrive Phil Daintree <p.d...@pa...>: > > > Hi Luca, > > > > There has been quite a bit of a discussion about multi-language - the= re > > are a lot of issues. Maybe I scare too easily, but it seems like a > > massive undertaking :-O > > > > Thanks so much for considering what is really quite a sizable project > > here. The other fear factor in taking this sort of thing on is if we > > start it I am the muggins that has a stuffed system if we can't finis= h > > it. It sure would be great to make web-erp multi-language. > > > > I see the way you are heading with what you started .... my over-ridi= ng > > and BIG worry in going to multi-language is that the code might becom= e > > more difficult to make sense of (of course it being in English must b= e > > quite a snag for those who use another language anyway). Under the > > scenario you are proposing we would, I guess have a varchar(30) > > description for the label that would be substituted by the TEXT field= . > > There a couple of reasons why I'm not that keen on this approach: > > > > 1. 30 characters isn't much to describe the text variable. The full > > context that the label provides I think significantly improves the > > ability to understand code. > > 2. If this requires a query for every label then this could be quite = an > > overhead on the db and a potential delay for the user. (all users). > > > > Of the approaches discussed in the developers list - there is an arch= ive > > of this http://sourceforge.net/mailarchive/forum.php?forum_id=3D34088 > > > > I prefer Steve Kaill's approach and the approach used in open-account= ing > > ie enclosing the the full label in a function call eg. > > > > echo language("This is how I rekon we should do multi-language so the > > code remains relatively easy to read"); > > > > the language function returns the language string required by the use= r. > > > > We hold a $_SESSION['language'] variable which is stored in the > > www_users table and retreived at the time of login. > > > > This language variable would be the same name as the file to include > > under a new languages directory. > > > > The function language would be in this include directory. > > > > The function language then takes the text of the english label as a > > parameter - the $SESSION['language'] is defined as global inside this > > function and returns the the language string appropriate - if there i= s > > no match for the string parameter passed then the parameter ie the > > english label is returned. > > > > The english language function in languages/english.php would just ret= urn > > the parameter itself. > > > > I have not gone down the track of considering if the label substituti= on > > is done using an array or what .... I would probably take a look at > > open-accounting logic. > > > > This approach does retain a critical requirement for webERP ie that o= f > > easily understandable code. > > > > All approaches have their down side - > > > > 1. This puts the overhead on the web-server/ php interpreter. However= , > > this is pretty fast.However,potentially significant memory is require= d - > > for what I have tried desperately to be minimalist in terms of resour= ces > > required to run it. > > > > 2. Anyone changing the english labels will stuff up the translation f= ile > > ie the include file of strings in english with the equivalent languag= e > > string! > > > > Do you see any other snags with this approach Luca? > > Could you consider a slightly different approach? > > > > Phil > > > > > > On Fri, 2004-07-30 at 17:12, ing. Luca Tur=3D?ISO-8859-1?Q?lon_Don=3D= E0?=3D > > wrote: > > > Hello Phil, > > > I've started to work on it. > > > Here is how I want to address the issue. > > > First I am going to create a table containing all the labels > > > > > > CREATE TABLE `languages` ( > > > `id` bigint(20) NOT NULL auto_increment, > > > `LANGID` varchar(15) NOT NULL default '', > > > `TEXTID` varchar(30) NOT NULL default '', > > > `TEXT` varchar(255) NOT NULL default '', > > > UNIQUE KEY `id` (`id`) > > > ) TYPE=3DInnoDB COMMENT=3D'Table containing labels to be showed on = the > > pages'; > > > > > > (I don't think InnoDB is necessary for this table, since it is only > > read by > > > normal users, and loaded by installer: i kept that type only for > > compatibility > > > with your design). > > > > > > TEXTID is a code that identifies a specific label in very page. Wit= h > > some work > > > we can undertsand if the same label is going to be used on diffrent > > pages. > > > TEXT is the text that is going to appear on the browser. > > > > > > On the config.php file I've inserted another variable: > > > $DefaultLanguage=3D"ITALIANO"; //of course you can put ENGLISH > > > > > > In session.inc i've inserted this line > > > include ("language.php"); > > > just after > > > include("includes/ConnectDB.inc"); > > > > > > As you can see in the attachment, language.php loads an array named > > $lang with > > > the contents of the table "languages". > > > By default it loads the $DefaultLanguage, but if the variable is no= t > > defined it > > > loads the English table. > > > > > > Then I simply substitute all the labels around the php and html cod= e > > with the > > > corresponding entry in the $lang array. > > > As an example you can see in the attached login.php file the follow= ing > > lines: 9, > > > 53, 57, 66. > > > > > > Having the labels in a db table can lead to another enhancement: ev= ery > > user can > > > choose his/her own language. This could be useful for companies hav= ing > > clients > > > spreaded around various countries.... > > > > > > What do you think about? > > > Can we arrange my small improvement with the future developement yo= u > > are making > > > in web-erp? > > > > > > Luca > > > > > > > > > Scrive Phil Daintree <p.d...@pa...>: > > > > > > > There has been some discussion about multi-language recently on t= he > > > > list. > > > > > > > > I am prepared to maintain a rigorous log of changes to scripts. > > Perhaps > > > > I could produce a diff file for all changes on each release but y= ou > > > > would have to apply these changes to the italian version. I have = had > > a > > > > similar request from a spanish speaking person. > > > > > > > > An Italian version would be good. > > > > > > > > web-erp is not ideally suited to multi-language as you point out > > since > > > > all labels, print and echo statements would need to be modified a= nd > > > > changes in the core scripts would need to be applied to each > > language's > > > > scripts manually. > > > > > > > > Phil > > > > > > > > > > > > On Thu, 2004-07-29 at 17:28, ing. Luca > > Tur=3D?ISO-8859-1?Q?lon_Don=3DE0?=3D > > > > wrote: > > > > > Dear Phil, > > > > > a couple of friends, who ar starting up a new fashion company h= ere > > in > > > > italy, > > > > > are very interested in using the application you developed. > > > > > > > > > > Since they're not very acquainted with the english language and > > > > jargon, i need > > > > > to translate the application for them. > > > > > > > > > > I have various ways to do this: one is to simply browse the cod= e > > and > > > > change > > > > > all the labels into italian. Doing so, i am very concerned abou= t > > > > everytime you > > > > > give a new release: at that time I have to check every change i= n > > every > > > > single > > > > > file. > > > > > The other one is to modify the code in order to have a separate > > place > > > > in which > > > > > labels and all the language-dependent stuff are stored. This ca= n > > be a > > > > DB table > > > > > or a file... i still don't know. > > > > > Before starting this, i need to know a couple of things: > > > > > First: are you going to do what I would like to do? In this cas= e > > when > > > > do you > > > > > think you will release a multilingual version of web-erp? And: = do > > you > > > > need any > > > > > help? I'd be happy to help in any way. > > > > > Second: if you're not going to do the multilingual version, can= I > > work > > > > on it? > > > > > Can we synch our two different tracks (the improvement of the > > system > > > > that > > > > > maybe you are doing and my translation-multilingual effort)? > > > > > > > > > > Please give me an answer on this, since i am strongly sponsorin= g > > your > > > > > product... > > > > > Best Regards, > > > > > Luca > > > > > > > > > > PS: I am working on the translation of the manual. When finishe= d, > > I'll > > > > send it > > > > > to you. > > > > > > > > > > > > ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Web-erp-developers mailing list Web...@li... https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: skaill <sk...@ro...> - 2004-08-02 22:11:10
|
Here is more information about the GNU gettext... http://www.gnu.org/software/gettext/gettext.html Just starting to read it myself but looks promising. Steve ----- Original Message ----- From: "Daintrees" <p.d...@pa...> To: <web...@li...> Cc: <luc...@pd...> Sent: Monday, August 02, 2004 4:21 PM Subject: [Web-erp-developers] Fw: Italian Translation of web-erp Luca, I am not sure if you have joined the developers list, but I have forwareded this email to them because I would like to run your proposal past the other interested and knowledgeable folk - hope you dont mind! We have a table of each script - that was added in 2.9 for the context sensitive help (currently not language specific) - each script is given a unique id - this may also be helpful for security Steve - the idea of retrieving just the labels for the script being run is appealing as is having a user interface for translators that doesnt involve editing files. You have some good points. The best point of all - you are prepared to do a lot of work for the project - most appreciated. Lets just see if there are any other opinions/pitfalls that the rest of the team see - so we dont trip and fall on this. Phil ----- Original Message ----- From: "ing. Luca Turlon Donà" <luc...@pd...> To: "Phil Daintree" <p.d...@pa...> Sent: Tuesday, August 03, 2004 12:11 AM Subject: Re: Italian Translation of web-erp > Hi Phil. > I've been reading thru your mail several times before answering, cause wanted > to be sure to understand every single issue ou pointed out. > > The main consideration that comes out is that your approach is very similar to > mine, i.e.: > -You are proposing a function call, I am proposing to use an array with a > literal index. > -You are proposing several files with the translation, i am proposing several > groups of rows in a table. > > Firts let me explain one thing: my idea consists in loading an array from the > db, i.e.: in the beginning of every page I make a bulk load of all the labels > in the language that has to be shown. So we do not have a full read cycle > (connect-query-parse the query, disconnect) on the db for every single label > in the page. We read everything at the beginning, load it in the lang array > and then use the lang array. This should address the second concern that you > put in your email. There is another thing: if we add a column on the db table, > containing the script (or an unique code which identifies the script) that is > going to be rendered we can achieve two more thing: first we can load just the > labels used in that script, reducing the size of the array. Secondly we will > have a documentation of what is shown in every page. > > Regarding the other concern, i.e. the smallness of 30 chars for a label > identifier, I believe that i could enlarge that column to a wider string: i do > not see any problem on this. > > The last thing you say, that is the code should be easy understandable. Maybe > you're right in considering the code easier to read having a full english > label, but I think that a label identifier with some comment could do the > same. In this way you could avoid the problem you mentioned about changes in > the english labels. > > Please now let me tell some other things about the "function" approach: > a) there is no other way than creating a php script to translate the > application. With the db approach I could create a page to let any kind of > user (not only a PHP programmer) manage the translation > b) it can become tough managing any new version of the system: with the db you > can query and see how many entries you have for each language, and you can > easily identify which labels has to be translated. With the included file > approach you have to work on the files, hoping that every file is written with > exactly the same approach. > c) Since you must delegate people to translate (unless you know at least 15 > languages) you can loose control on the code: what if a russian sends you an > email saying that the system not working, just because the russian translator > forgot a ";" in his code? With the db approach the worst thing that could > happen is a wrong translation or something written in English, but not > something that halts the system. > d) With the db you have a sort of documentation, which can help in creating > help files... > e) it is at any time possible to automatically generate any language script, > i.e a language/italiano.php can be generated from the db and we can switch to > your "function" approach. > f) ther is another thing regarding the usage of the entire english label as a > parameter: imagine if you forget to put the function call. With the label > identifier you immediately see that there is something difficult to read on > the page. With the full english label you may even not notice the error. > > > Finally: I do believe that the language variable should be kept, in the > future, in the session of the user, having each user working with his/her own > language. For now I am just using a default language, but in the future it can > be changed. > > One very last thing: I have to work on it, 'cause these friends of mine needs > it, and I will work on the application making it multilanguage. I will go thru > the entire application, populating the db tables and changing the scripts > where needed. After I will finish my job, I believe by the end of september, I > am going to send you the result of my job: thus you'll get a finished a work, > and you'd be not worried by having something not finished. The only thing is > to understand what has changed from noew (or better from the 2.9 release of > the system) till the end of september. > > Luca > > Scrive Phil Daintree <p.d...@pa...>: > > > Hi Luca, > > > > There has been quite a bit of a discussion about multi-language - there > > are a lot of issues. Maybe I scare too easily, but it seems like a > > massive undertaking :-O > > > > Thanks so much for considering what is really quite a sizable project > > here. The other fear factor in taking this sort of thing on is if we > > start it I am the muggins that has a stuffed system if we can't finish > > it. It sure would be great to make web-erp multi-language. > > > > I see the way you are heading with what you started .... my over-riding > > and BIG worry in going to multi-language is that the code might become > > more difficult to make sense of (of course it being in English must be > > quite a snag for those who use another language anyway). Under the > > scenario you are proposing we would, I guess have a varchar(30) > > description for the label that would be substituted by the TEXT field. > > There a couple of reasons why I'm not that keen on this approach: > > > > 1. 30 characters isn't much to describe the text variable. The full > > context that the label provides I think significantly improves the > > ability to understand code. > > 2. If this requires a query for every label then this could be quite an > > overhead on the db and a potential delay for the user. (all users). > > > > Of the approaches discussed in the developers list - there is an archive > > of this http://sourceforge.net/mailarchive/forum.php?forum_id=34088 > > > > I prefer Steve Kaill's approach and the approach used in open-accounting > > ie enclosing the the full label in a function call eg. > > > > echo language("This is how I rekon we should do multi-language so the > > code remains relatively easy to read"); > > > > the language function returns the language string required by the user. > > > > We hold a $_SESSION['language'] variable which is stored in the > > www_users table and retreived at the time of login. > > > > This language variable would be the same name as the file to include > > under a new languages directory. > > > > The function language would be in this include directory. > > > > The function language then takes the text of the english label as a > > parameter - the $SESSION['language'] is defined as global inside this > > function and returns the the language string appropriate - if there is > > no match for the string parameter passed then the parameter ie the > > english label is returned. > > > > The english language function in languages/english.php would just return > > the parameter itself. > > > > I have not gone down the track of considering if the label substitution > > is done using an array or what .... I would probably take a look at > > open-accounting logic. > > > > This approach does retain a critical requirement for webERP ie that of > > easily understandable code. > > > > All approaches have their down side - > > > > 1. This puts the overhead on the web-server/ php interpreter. However, > > this is pretty fast.However,potentially significant memory is required - > > for what I have tried desperately to be minimalist in terms of resources > > required to run it. > > > > 2. Anyone changing the english labels will stuff up the translation file > > ie the include file of strings in english with the equivalent language > > string! > > > > Do you see any other snags with this approach Luca? > > Could you consider a slightly different approach? > > > > Phil > > > > > > On Fri, 2004-07-30 at 17:12, ing. Luca Tur=?ISO-8859-1?Q?lon_Don=E0?= > > wrote: > > > Hello Phil, > > > I've started to work on it. > > > Here is how I want to address the issue. > > > First I am going to create a table containing all the labels > > > > > > CREATE TABLE `languages` ( > > > `id` bigint(20) NOT NULL auto_increment, > > > `LANGID` varchar(15) NOT NULL default '', > > > `TEXTID` varchar(30) NOT NULL default '', > > > `TEXT` varchar(255) NOT NULL default '', > > > UNIQUE KEY `id` (`id`) > > > ) TYPE=InnoDB COMMENT='Table containing labels to be showed on the > > pages'; > > > > > > (I don't think InnoDB is necessary for this table, since it is only > > read by > > > normal users, and loaded by installer: i kept that type only for > > compatibility > > > with your design). > > > > > > TEXTID is a code that identifies a specific label in very page. With > > some work > > > we can undertsand if the same label is going to be used on diffrent > > pages. > > > TEXT is the text that is going to appear on the browser. > > > > > > On the config.php file I've inserted another variable: > > > $DefaultLanguage="ITALIANO"; //of course you can put ENGLISH > > > > > > In session.inc i've inserted this line > > > include ("language.php"); > > > just after > > > include("includes/ConnectDB.inc"); > > > > > > As you can see in the attachment, language.php loads an array named > > $lang with > > > the contents of the table "languages". > > > By default it loads the $DefaultLanguage, but if the variable is not > > defined it > > > loads the English table. > > > > > > Then I simply substitute all the labels around the php and html code > > with the > > > corresponding entry in the $lang array. > > > As an example you can see in the attached login.php file the following > > lines: 9, > > > 53, 57, 66. > > > > > > Having the labels in a db table can lead to another enhancement: every > > user can > > > choose his/her own language. This could be useful for companies having > > clients > > > spreaded around various countries.... > > > > > > What do you think about? > > > Can we arrange my small improvement with the future developement you > > are making > > > in web-erp? > > > > > > Luca > > > > > > > > > Scrive Phil Daintree <p.d...@pa...>: > > > > > > > There has been some discussion about multi-language recently on the > > > > list. > > > > > > > > I am prepared to maintain a rigorous log of changes to scripts. > > Perhaps > > > > I could produce a diff file for all changes on each release but you > > > > would have to apply these changes to the italian version. I have had > > a > > > > similar request from a spanish speaking person. > > > > > > > > An Italian version would be good. > > > > > > > > web-erp is not ideally suited to multi-language as you point out > > since > > > > all labels, print and echo statements would need to be modified and > > > > changes in the core scripts would need to be applied to each > > language's > > > > scripts manually. > > > > > > > > Phil > > > > > > > > > > > > On Thu, 2004-07-29 at 17:28, ing. Luca > > Tur=?ISO-8859-1?Q?lon_Don=E0?= > > > > wrote: > > > > > Dear Phil, > > > > > a couple of friends, who ar starting up a new fashion company here > > in > > > > italy, > > > > > are very interested in using the application you developed. > > > > > > > > > > Since they're not very acquainted with the english language and > > > > jargon, i need > > > > > to translate the application for them. > > > > > > > > > > I have various ways to do this: one is to simply browse the code > > and > > > > change > > > > > all the labels into italian. Doing so, i am very concerned about > > > > everytime you > > > > > give a new release: at that time I have to check every change in > > every > > > > single > > > > > file. > > > > > The other one is to modify the code in order to have a separate > > place > > > > in which > > > > > labels and all the language-dependent stuff are stored. This can > > be a > > > > DB table > > > > > or a file... i still don't know. > > > > > Before starting this, i need to know a couple of things: > > > > > First: are you going to do what I would like to do? In this case > > when > > > > do you > > > > > think you will release a multilingual version of web-erp? And: do > > you > > > > need any > > > > > help? I'd be happy to help in any way. > > > > > Second: if you're not going to do the multilingual version, can I > > work > > > > on it? > > > > > Can we synch our two different tracks (the improvement of the > > system > > > > that > > > > > maybe you are doing and my translation-multilingual effort)? > > > > > > > > > > Please give me an answer on this, since i am strongly sponsoring > > your > > > > > product... > > > > > Best Regards, > > > > > Luca > > > > > > > > > > PS: I am working on the translation of the manual. When finished, > > I'll > > > > send it > > > > > to you. > > > > > > > > > > > > ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Web-erp-developers mailing list Web...@li... https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Daintrees <p.d...@pa...> - 2004-08-03 00:54:52
|
I forwarded your comments to Luca - I dont think hes on the list. Gettext is the way open-accounting did it. Phil ----- Original Message -----=20 =46rom: "skaill" <sk...@ro...> To: <web...@li...> Sent: Tuesday, August 03, 2004 10:01 AM Subject: Re: [Web-erp-developers] Fw: Italian Translation of web-erp > This is an area that we will need to work on as well. If Luca want= s to "get > together" at some point to work on this I am available. > > I would point out to Luca that keeping the original English strings= in the > code instead of using an identifier keeps the code WAY more readabl= e. > That's my opinion after having worked extensively with a product th= at did it > with identifiers. Code is scary to read when it has identifiers in= stead of > literals. Many will be thrown off by doing that. > > I have recently discovered a function in PHP called gettext which m= ay be for > exactly what we are trying to do. I don't know enough about it but= before > doing our own coding for Multilanguage it would be nice to see if t= he built > in gettext functionality will do it. > > Just guessing but I think loading the entire language file at the beginning > of each page may be much slower than doing a few reads within one p= age. A > few lines versus hundreds to thousands. Plus the memory for each u= ser would > be way more. Here's an idea that actually ends up a modified versi= on of > Luca's suggestion to keep the page number in the db. Have an array= of > strings at the top of each page where those strings are the strings= used > within the page. Call a language function that retrieves and retur= ns all of > these at the page beginning. When language(...) is called within t= he page, > it first looks to see if the string was looked up already and uses = that > otherwise goes out to retrieve from the db, file or wherever. This= will > minimize the amount needing to be looked up yet look it up (or most= of it) > all at once as Luca is suggesting. > > We can build in whatever is changed until September very easily. I= t's just > important to know which version Luca started on. > > I agree that db storage is the best for the Multilanguage informati= on over > another way such as file. > > Steve > > ----- Original Message -----=20 > From: "Daintrees" <p.d...@pa...> > To: <web...@li...> > Cc: <luc...@pd...> > Sent: Monday, August 02, 2004 4:21 PM > Subject: [Web-erp-developers] Fw: Italian Translation of web-erp > > > Luca, > > I am not sure if you have joined the developers list, but I have forwareded > this email to them because I would like to run your proposal past t= he other > interested and knowledgeable folk - hope you dont mind! > > We have a table of each script - that was added in 2.9 for the cont= ext > sensitive help (currently not language specific) - each script is g= iven a > unique id - this may also be helpful for security Steve - the idea = of > retrieving just the labels for the script being run is appealing as= is > having a user interface for translators that doesnt involve editing= files. > You have some good points. The best point of all - you are prepared= to do a > lot of work for the project - most appreciated. > > Lets just see if there are any other opinions/pitfalls that the res= t of the > team see - so we dont trip and fall on this. > > Phil > > ----- Original Message -----=20 > From: "ing. Luca Turlon Don=E0" <luc...@pd...> > To: "Phil Daintree" <p.d...@pa...> > Sent: Tuesday, August 03, 2004 12:11 AM > Subject: Re: Italian Translation of web-erp > > > > Hi Phil. > > I've been reading thru your mail several times before answering, = cause > wanted > > to be sure to understand every single issue ou pointed out. > > > > The main consideration that comes out is that your approach is ve= ry > similar to > > mine, i.e.: > > -You are proposing a function call, I am proposing to use an arra= y with a > > literal index. > > -You are proposing several files with the translation, i am propo= sing > several > > groups of rows in a table. > > > > Firts let me explain one thing: my idea consists in loading an ar= ray =66rom > the > > db, i.e.: in the beginning of every page I make a bulk load of al= l the > labels > > in the language that has to be shown. So we do not have a full re= ad cycle > > (connect-query-parse the query, disconnect) on the db for every s= ingle > label > > in the page. We read everything at the beginning, load it in the = lang > array > > and then use the lang array. This should address the second conce= rn that > you > > put in your email. There is another thing: if we add a column on = the db > table, > > containing the script (or an unique code which identifies the scr= ipt) that > is > > going to be rendered we can achieve two more thing: first we can = load just > the > > labels used in that script, reducing the size of the array. Secon= dly we > will > > have a documentation of what is shown in every page. > > > > Regarding the other concern, i.e. the smallness of 30 chars for a= label > > identifier, I believe that i could enlarge that column to a wider string: > i do > > not see any problem on this. > > > > The last thing you say, that is the code should be easy understan= dable. > Maybe > > you're right in considering the code easier to read having a full english > > label, but I think that a label identifier with some comment coul= d do the > > same. In this way you could avoid the problem you mentioned about changes > in > > the english labels. > > > > Please now let me tell some other things about the "function" app= roach: > > a) there is no other way than creating a php script to translate = the > > application. With the db approach I could create a page to let an= y kind of > > user (not only a PHP programmer) manage the translation > > b) it can become tough managing any new version of the system: wi= th the db > you > > can query and see how many entries you have for each language, an= d you can > > easily identify which labels has to be translated. With the inclu= ded file > > approach you have to work on the files, hoping that every file is written > with > > exactly the same approach. > > c) Since you must delegate people to translate (unless you know a= t least > 15 > > languages) you can loose control on the code: what if a russian s= ends you > an > > email saying that the system not working, just because the russia= n > translator > > forgot a ";" in his code? With the db approach the worst thing th= at could > > happen is a wrong translation or something written in English, bu= t not > > something that halts the system. > > d) With the db you have a sort of documentation, which can help i= n > creating > > help files... > > e) it is at any time possible to automatically generate any langu= age > script, > > i.e a language/italiano.php can be generated from the db and we c= an switch > to > > your "function" approach. > > f) ther is another thing regarding the usage of the entire englis= h label > as a > > parameter: imagine if you forget to put the function call. With t= he label > > identifier you immediately see that there is something difficult = to read > on > > the page. With the full english label you may even not notice the= error. > > > > > > Finally: I do believe that the language variable should be kept, = in the > > future, in the session of the user, having each user working with his/her > own > > language. For now I am just using a default language, but in the = future it > can > > be changed. > > > > One very last thing: I have to work on it, 'cause these friends o= f mine > needs > > it, and I will work on the application making it multilanguage. I= will go > thru > > the entire application, populating the db tables and changing the scripts > > where needed. After I will finish my job, I believe by the end of > september, I > > am going to send you the result of my job: thus you'll get a fini= shed a > work, > > and you'd be not worried by having something not finished. The on= ly thing > is > > to understand what has changed from noew (or better from the 2.9 = release > of > > the system) till the end of september. > > > > Luca > > > > Scrive Phil Daintree <p.d...@pa...>: > > > > > Hi Luca, > > > > > > There has been quite a bit of a discussion about multi-language= - there > > > are a lot of issues. Maybe I scare too easily, but it seems lik= e a > > > massive undertaking :-O > > > > > > Thanks so much for considering what is really quite a sizable p= roject > > > here. The other fear factor in taking this sort of thing on is = if we > > > start it I am the muggins that has a stuffed system if we can't= finish > > > it. It sure would be great to make web-erp multi-language. > > > > > > I see the way you are heading with what you started .... my over-riding > > > and BIG worry in going to multi-language is that the code might= become > > > more difficult to make sense of (of course it being in English = must be > > > quite a snag for those who use another language anyway). Under = the > > > scenario you are proposing we would, I guess have a varchar(30) > > > description for the label that would be substituted by the TEXT= field. > > > There a couple of reasons why I'm not that keen on this approac= h: > > > > > > 1. 30 characters isn't much to describe the text variable. The = full > > > context that the label provides I think significantly improves = the > > > ability to understand code. > > > 2. If this requires a query for every label then this could be = quite an > > > overhead on the db and a potential delay for the user. (all use= rs). > > > > > > Of the approaches discussed in the developers list - there is a= n archive > > > of this http://sourceforge.net/mailarchive/forum.php?forum_id= =3D34088 > > > > > > I prefer Steve Kaill's approach and the approach used in open-accounting > > > ie enclosing the the full label in a function call eg. > > > > > > echo language("This is how I rekon we should do multi-language = so the > > > code remains relatively easy to read"); > > > > > > the language function returns the language string required by t= he user. > > > > > > We hold a $_SESSION['language'] variable which is stored in the > > > www_users table and retreived at the time of login. > > > > > > This language variable would be the same name as the file to in= clude > > > under a new languages directory. > > > > > > The function language would be in this include directory. > > > > > > The function language then takes the text of the english label = as a > > > parameter - the $SESSION['language'] is defined as global insid= e this > > > function and returns the the language string appropriate - if t= here is > > > no match for the string parameter passed then the parameter ie = the > > > english label is returned. > > > > > > The english language function in languages/english.php would ju= st return > > > the parameter itself. > > > > > > I have not gone down the track of considering if the label substitution > > > is done using an array or what .... I would probably take a loo= k at > > > open-accounting logic. > > > > > > This approach does retain a critical requirement for webERP ie = that of > > > easily understandable code. > > > > > > All approaches have their down side - > > > > > > 1. This puts the overhead on the web-server/ php interpreter. H= owever, > > > this is pretty fast.However,potentially significant memory is required - > > > for what I have tried desperately to be minimalist in terms of resources > > > required to run it. > > > > > > 2. Anyone changing the english labels will stuff up the transla= tion file > > > ie the include file of strings in english with the equivalent l= anguage > > > string! > > > > > > Do you see any other snags with this approach Luca? > > > Could you consider a slightly different approach? > > > > > > Phil > > > > > > > > > On Fri, 2004-07-30 at 17:12, ing. Luca Tur=3D?ISO-8859-1?Q?lon_= Don=3DE0?=3D > > > wrote: > > > > Hello Phil, > > > > I've started to work on it. > > > > Here is how I want to address the issue. > > > > First I am going to create a table containing all the labels > > > > > > > > CREATE TABLE `languages` ( > > > > `id` bigint(20) NOT NULL auto_increment, > > > > `LANGID` varchar(15) NOT NULL default '', > > > > `TEXTID` varchar(30) NOT NULL default '', > > > > `TEXT` varchar(255) NOT NULL default '', > > > > UNIQUE KEY `id` (`id`) > > > > ) TYPE=3DInnoDB COMMENT=3D'Table containing labels to be show= ed on the > > > pages'; > > > > > > > > (I don't think InnoDB is necessary for this table, since it i= s only > > > read by > > > > normal users, and loaded by installer: i kept that type only = for > > > compatibility > > > > with your design). > > > > > > > > TEXTID is a code that identifies a specific label in very pag= e. With > > > some work > > > > we can undertsand if the same label is going to be used on di= ffrent > > > pages. > > > > TEXT is the text that is going to appear on the browser. > > > > > > > > On the config.php file I've inserted another variable: > > > > $DefaultLanguage=3D"ITALIANO"; //of course you can put ENGLIS= H > > > > > > > > In session.inc i've inserted this line > > > > include ("language.php"); > > > > just after > > > > include("includes/ConnectDB.inc"); > > > > > > > > As you can see in the attachment, language.php loads an array= named > > > $lang with > > > > the contents of the table "languages". > > > > By default it loads the $DefaultLanguage, but if the variable= is not > > > defined it > > > > loads the English table. > > > > > > > > Then I simply substitute all the labels around the php and ht= ml code > > > with the > > > > corresponding entry in the $lang array. > > > > As an example you can see in the attached login.php file the following > > > lines: 9, > > > > 53, 57, 66. > > > > > > > > Having the labels in a db table can lead to another enhanceme= nt: every > > > user can > > > > choose his/her own language. This could be useful for compani= es having > > > clients > > > > spreaded around various countries.... > > > > > > > > What do you think about? > > > > Can we arrange my small improvement with the future developem= ent you > > > are making > > > > in web-erp? > > > > > > > > Luca > > > > > > > > > > > > Scrive Phil Daintree <p.d...@pa...>: > > > > > > > > > There has been some discussion about multi-language recentl= y on the > > > > > list. > > > > > > > > > > I am prepared to maintain a rigorous log of changes to scri= pts. > > > Perhaps > > > > > I could produce a diff file for all changes on each release= but you > > > > > would have to apply these changes to the italian version. I= have had > > > a > > > > > similar request from a spanish speaking person. > > > > > > > > > > An Italian version would be good. > > > > > > > > > > web-erp is not ideally suited to multi-language as you poin= t out > > > since > > > > > all labels, print and echo statements would need to be modi= fied and > > > > > changes in the core scripts would need to be applied to eac= h > > > language's > > > > > scripts manually. > > > > > > > > > > Phil > > > > > > > > > > > > > > > On Thu, 2004-07-29 at 17:28, ing. Luca > > > Tur=3D?ISO-8859-1?Q?lon_Don=3DE0?=3D > > > > > wrote: > > > > > > Dear Phil, > > > > > > a couple of friends, who ar starting up a new fashion com= pany here > > > in > > > > > italy, > > > > > > are very interested in using the application you develope= d. > > > > > > > > > > > > Since they're not very acquainted with the english langua= ge and > > > > > jargon, i need > > > > > > to translate the application for them. > > > > > > > > > > > > I have various ways to do this: one is to simply browse t= he code > > > and > > > > > change > > > > > > all the labels into italian. Doing so, i am very concerne= d about > > > > > everytime you > > > > > > give a new release: at that time I have to check every ch= ange in > > > every > > > > > single > > > > > > file. > > > > > > The other one is to modify the code in order to have a se= parate > > > place > > > > > in which > > > > > > labels and all the language-dependent stuff are stored. T= his can > > > be a > > > > > DB table > > > > > > or a file... i still don't know. > > > > > > Before starting this, i need to know a couple of things: > > > > > > First: are you going to do what I would like to do? In th= is case > > > when > > > > > do you > > > > > > think you will release a multilingual version of web-erp?= And: do > > > you > > > > > need any > > > > > > help? I'd be happy to help in any way. > > > > > > Second: if you're not going to do the multilingual versio= n, can I > > > work > > > > > on it? > > > > > > Can we synch our two different tracks (the improvement of= the > > > system > > > > > that > > > > > > maybe you are doing and my translation-multilingual effor= t)? > > > > > > > > > > > > Please give me an answer on this, since i am strongly spo= nsoring > > > your > > > > > > product... > > > > > > Best Regards, > > > > > > Luca > > > > > > > > > > > > PS: I am working on the translation of the manual. When finished, > > > I'll > > > > > send it > > > > > > to you. > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the change= s on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? N= ow, > one more big change to announce. We are now OSTG- Open Source Techn= ology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the change= s on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? N= ow, > one more big change to announce. We are now OSTG- Open Source Techn= ology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
×
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