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

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

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
>