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

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

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 did it
with identifiers.  Code is scary to read when it has identifiers instead of
literals.  Many will be thrown off by doing that.

I have recently discovered a function in PHP called gettext which may 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 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
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 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 returns all 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 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.  It's just
important to know which version Luca started on.

I agree that db storage is the best for the Multilanguage information over
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 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