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

[Stins, D. <DR...@Zi...>]

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