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

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

It looks like the best way to do Multilanguage is using gettext.  I'm not
saying it can't be done another way but a huge ongoing project exists that
supports it and several Open Source programs use it.  Using this method
would mean we have support and a supply of tools/code examples to get the
job done. Getting language files for various languages contributed from
others would be easier.  Also, for all developers in the future they will
likely know gettext over anything else and combining Multilanguage softwares
would be easier.  It really turns out very easy and is basically identical
to the ways of doing it that we have been discussing.

One issue with gettext is you may have to install the gettext facility into
php.  I'm not sure if it comes with it, however the php manual does discuss
it.

I found an example Open Source program that uses the gettext facility that
could serve as an example.

The only challenge now is how to create the language files it uses.  I
believe there are good tools available for doing it that help create, manage
and track.  Just haven't looked into that part yet.

Steve

----- Original Message ----- 
From: "skaill" <sk...@ro...>
To: <web...@li...>
Sent: Monday, August 02, 2004 6:11 PM
Subject: Re: [Web-erp-developers] Fw: Italian Translation of web-erp


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