Forums / Suggestions / Idea for improvement of i18n translation system

Idea for improvement of i18n translation system

« 
Previous topic
|
Suggestions
|
Next topic
 »
Author Message

Maurizio Betti

Friday 19 December 2008 1:48:48 pm

Hi all,

I'm currently building up a new multi-language website and I've to customize both some system messages (es. in login page) and some custom messages.

Now: with the current system I insert a string and mark it with i18n, then I go to .ts file and create the relative voice (equal to my string). Then repeat this operation with all .ts files for each language.

This system sucks for many causes:
1. If I have to modify it later, I must modify the marked string in all .ts files
2. The same message has often to be modified:
- for native languages directly by the editors (in order to improve it)
- for translating strings by the translation agency (often an external agency)

This is very uncomfortable because I have to manage the different versions and modifications on different .ts files, and I send files by email to many people. In addition always the editors (or translation agency) that write the text has not technical skills for use QT or other xml editor.

The result is that many messages remain in technical language (always different from human language provide by an editor :-) and many translations uncompleted.

What would be a great solution?

Just to move the translation system to admin interface as "ezcontentobject".

I tried to do this by creating a "Translation" class and give it a "text" attribute. In this way I can create several objects, call it directly from code as ezcontentobject and place in tpl without think anything about the translation or message to insert.

On the other side I give to my customers and translation agency, the possibility to modify it simply from admin interface (using the provided translation mechanism for objects) without learn how to handle a .ts file.

We had a great improvement with this system in order to provide more accurate messages in the web site and to make easy the manage messages translation.

I think this is a solution quite better than original system and I hope this idea could be help others eZ users.

At the same time let me invite eZ developers team to provide a build-in mechanism (more sophisticated than a Class) which could be substitute gradually the actual i18n system with the hack described.

Best regards,
Maurizio Betti

Maurizio Betti
http://www.arsweb.it
http://www.hospes.it

Carlos Revillo

Friday 19 December 2008 11:17:01 pm

i would prefer let the ezcontentobject table just for content and not for other things. correct me if i'm wrong, but if you have 12 literals for example in a template, you'll need 12 fetch("content", "object") calls for getting the literal, and then work with data_map of this object?. for literals located at pagelayout, those queries will be executed everytime you request a page (if you don't use cache-blocks, i mean).

The idea of admin translations in the admin site is good either. what about provide an interface to work with .ts files?

Piotrek Karaś

Saturday 20 December 2008 11:06:41 am

Hi Maurizio,

I have started developing a translation tool. The basic concept was to enable easy, editorial, multi-user translation collaboration as well as some automated translation management. Some of the tools include source or translation import (so that you can in seconds prepare a file for translation from any language to any language), change highlighting, exports, etc.

This tool would not have solved methodology problems, only facilitate working on *.ts file. Unfortunately, I haven't really finished it and I have no idea when I will. I could share this as soon as I put it to any shape that makes sense for others...

Also, we've covered some common translation issues and approaches here:
http://ez.no/developer/forum/setup_design/how_to_actually_use_dictionaries_ezlupdate_et_al/re_how_to_actually_use_dictionaries_ezlu__2

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Björn [email protected]

Monday 22 December 2008 3:47:30 am

TS is crap and not a standard like TMX.

http://www.lisa.org/fileadmin/standards/tmx1.4/tmx.htm

This is how TMX markup would looke like it is more suited to what we need.

<?xml version="1.0"?>
<!-- Example of TMX document -->
<tmx version="1.4">
 <header
  creationtool="XYZTool"
  creationtoolversion="1.01-023"
  datatype="PlainText"
  segtype="sentence"
  adminlang="en-us"
  srclang="EN"
  o-tmf="ABCTransMem"
  creationdate="20020101T163812Z"
  creationid="ThomasJ"
  changedate="20020413T023401Z"
  changeid="Amity"
  o-encoding="iso-8859-1"
 >
  <note>This is a note at document level.</note>
  <prop type="RTFPreamble">{\rtf1\ansi\tag etc...{\fonttbl}</prop>
  <ude name="MacRoman" base="Macintosh">
   <map unicode="#xF8FF" code="#xF0" ent="Apple_logo" subst="[Apple]"/>
  </ude>
 </header>
 <body>
  <tu
   tuid="0001"
   datatype="Text"
   usagecount="2"
   lastusagedate="19970314T023401Z"
  >
   <note>Text of a note at the TU level.</note>
   <prop type="x-Domain">Computing</prop>
   <prop type="x-Project">P&#x00E6;gasus</prop>
   <tuv
    xml:lang="EN"
    creationdate="19970212T153400Z"
    creationid="BobW"
   >
    <seg>data (with a non-standard character: &#xF8FF;).</seg>
   </tuv>
   <tuv
    xml:lang="FR-CA"
    creationdate="19970309T021145Z"
    creationid="BobW"
    changedate="19970314T023401Z"
    changeid="ManonD"
   >
    <prop type="Origin">MT</prop>
    <seg>donn&#xE9;es (avec un caract&#xE8;re non standard: &#xF8FF;).</seg>
   </tuv>
  </tu>
  <tu
   tuid="0002"
   srclang="*all*"
  >
   <prop type="Domain">Cooking</prop>
   <tuv xml:lang="EN">
    <seg>menu</seg>
   </tuv>
   <tuv xml:lang="FR-CA">
    <seg>menu</seg>
   </tuv>
   <tuv xml:lang="FR-FR">
    <seg>menu</seg>
   </tuv>
  </tu>
 </body>
</tmx>

Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs
Looking for hosting? http://hostingezpublish.com
-----------------------------------------------------------------------------
GMT +01:00 Hannover, Germany
Web: http://www.xrow.com/

Maurizio Betti

Monday 22 December 2008 7:27:34 am

I know there are some big iusses and limitations on my approach. Carlos wrote well about fetch performance, and there is also some problem in parametrize some variables in the message.

Piotrek thank you for the reply. I will take a look to Addicted contrib.

Regards,
Maurizio

Maurizio Betti
http://www.arsweb.it
http://www.hospes.it