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

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

Great that Luca would like to implement this functionality.

When this solution does not what we expect, then we can always consider t=
o
try to create a generate script which generate a script to fill the array
from the database which Luca is creating or generate some other better
solution.

Performance might vary per version of apache, linux, mysql, php and is no=
t
always logical. Like I read that read that session variables are always r=
ead
from disks (slow) and you might think that it is faster because you  migh=
t
think that it you have tto load only once the translation array compared =
to
loading it for every page again (solution of Luca). When the loading of t=
he
array for every page is cached in RAM, then it's faster then loading once=
 in
session variables.

Luca: Let's see what happens! Success!

With best regards,

Dick Stins
----- Original Message -----
From: "Daintrees" <p.d...@pa...>
To: <web...@li...>
Cc: <luc...@pd...>
Sent: Monday, August 02, 2004 10: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 forwared=
ed
this email to them because I would like to run your proposal past the oth=
er
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 t=
he
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, 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 fr=
om
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 cyc=
le
> (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 tha=
t
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) t=
hat
is
> going to be rendered we can achieve two more thing: first we can load j=
ust
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 strin=
g:
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 engli=
sh
> label, but I think that a label identifier with some comment could do t=
he
> same. In this way you could avoid the problem you mentioned about chang=
es
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 fi=
le
> approach you have to work on the files, hoping that every file is writt=
en
with
> exactly the same approach.
> c) Since you must delegate people to translate (unless you know at leas=
t
15
> languages) you can loose control on the code: what if a russian sends y=
ou
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 cou=
ld
> 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 swi=
tch
to
> your "function" approach.
> f) ther is another thing regarding the usage of the entire english labe=
l
as a
> parameter: imagine if you forget to put the function call. With the lab=
el
> identifier you immediately see that there is something difficult to rea=
d
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/h=
er
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  scri=
pts
> 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 thi=
ng
is
> to understand what has changed from noew (or better from the 2.9 releas=
e
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 - the=
re
> > 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 finis=
h
> > 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-ridi=
ng
> > and BIG worry in going to multi-language is that the code might becom=
e
> > more difficult to make sense of (of course it being in English must b=
e
> > 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 arch=
ive
> > of this http://sourceforge.net/mailarchive/forum.php?forum_id=3D34088
> >
> > I prefer Steve Kaill's approach and the approach used in open-account=
ing
> > 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 use=
r.
> >
> > 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 i=
s
> > 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 ret=
urn
> > the parameter itself.
> >
> > I have not gone down the track of considering if the label substituti=
on
> > 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 o=
f
> > 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 require=
d -
> > for what I have tried desperately to be minimalist in terms of resour=
ces
> > required to run it.
> >
> > 2. Anyone changing the english labels will stuff up the translation f=
ile
> > ie the include file of strings in english with the equivalent languag=
e
> > 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 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. Wit=
h
> > 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=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 named
> > $lang with
> > > the contents of the table "languages".
> > > By default it loads the $DefaultLanguage, but if the variable is no=
t
> > defined it
> > > loads the English table.
> > >
> > > Then I simply substitute all the labels around the php and html cod=
e
> > with the
> > > corresponding entry in the $lang array.
> > > As an example you can see in the attached login.php file the follow=
ing
> > lines: 9,
> > > 53, 57, 66.
> > >
> > > Having the labels in a db table can lead to another enhancement: ev=
ery
> > user can
> > > choose his/her own language. This could be useful for companies hav=
ing
> > clients
> > > spreaded around various countries....
> > >
> > > What do you think about?
> > > Can we arrange my small improvement with the future developement yo=
u
> > are making
> > > in web-erp?
> > >
> > > Luca
> > >
> > >
> > > Scrive Phil Daintree <p.d...@pa...>:
> > >
> > > > There has been some discussion about multi-language recently on t=
he
> > > > 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 y=
ou
> > > > 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 a=
nd
> > > > 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 h=
ere
> > 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 cod=
e
> > and
> > > > change
> > > > > all the labels into italian. Doing so, i am very concerned abou=
t
> > > > everytime you
> > > > > give a new release: at that time I have to check every change i=
n
> > 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 ca=
n
> > 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 cas=
e
> > 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 sponsorin=
g
> > your
> > > > > product...
> > > > > Best Regards,
> > > > > Luca
> > > > >
> > > > > PS: I am working on the translation of the manual. When finishe=
d,
> > 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