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

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

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