[Web-erp-developers] Re: Italian Translation of web-erp

[Phil D. <p.d...@pa...>]

Luca,

Hope you dont mind - I subscribed you to the developers list - you have
to confirm if you wish to receive email discussion of web-erp
development.

I re-read you first email and I didn't understand correctly first time
out - I like your approach. I also like the idea of retaining the full
english text in the code somehow. It does seem that those in the know
like this gettext function I have not read up on it myself but bow to
those with the knowledge. I also have great respect for Sherif Omar and
Hani Nguaeb (hope he'll forgive my spelling of his surname!) who forked
web-erp into Open Accounting the last time multi-language raised itself
- I didn't have the stomach for it at the time!! Gettext was the way
they went. 

You know the issues I have :

1. Readability and ease of understanding the code
2. Readability and ease of understanding the code
3. Readability and ease of understanding the code
4, 5  and 6. Efficiency of the code (minising DB calls/Web server
parsing)

If these issues are satisfied then lets GO!

Phil

On Mon, 2004-08-02 at 13:11, ing. Luca Tur=?ISO-8859-1?Q?lon_Don=E0?=
wrote:
> 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.
> > > > > 
> > > > 
> > 
>