forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Multilingual sites
Date Fri, 14 Jun 2002 09:47:15 GMT
I have the principle of deciding if I model something as an attribute or as
an element the following way:

If I strip all the tags, everything that stays must be relevant for a user,
and nothing of the content must have been lost.  Only structure and
identification, keys, processing instructions, etc. are removed.

So, I agree with Sylvain, saying that 
"Moreover, I don't think it's good to have text that gets displayed to the
modelled as attributes "

And I don't agree with the idea of having to translate attributes as
Konstantin noted:
"And how would you translate attributes (sometimes you'll need it too)?"

And Sylvain is right, "translations *are* the content !"

We use here "working languages" in which the decisions and regulations are
made, and for which each of the translation IS the rule (you don't need to
refer to an original text).

Pierre A. Damas
European Commission

-----Original Message-----
From: Sylvain Wallez []
Sent: Friday, June 14, 2002 11:32
Subject: Re: Multilingual sites

Konstantin Piroumian wrote:

>From: "Sylvain Wallez" <>
>>Hi forresters,
>>I'm currently considering the use of Forrest to rebuild the static part
>>of my company's website. However, our site needs to be multilingual (at
>>least french and english), and I'd like to share some thoughts and have
>>your opinion.
>>An important hypothesis is that the site will provide the same content
>>for all languages. So my idea is to have each xdoc file contain the same
>>content in the different languages in order to both ease translation
>>work and ensure structural consistency.
>Why not to use i18n transformer and have translations in separate
>files? How would having all translations in content ease the translation
>work? Your translators should go through all the xdocs and duplicate all
>elements. And how would you translate attributes (sometimes you'll need it

I use a lot i18n transformer, but for data-oriented pages which contain 
text elements that do not constitute a document (button, form input 
labels, table column title, error messages, etc).

>Of course, if the number of pages is not big then your approach is Ok, but
>wouldn't recommend to mix translations and the content.

But translations *are* the content !

>>Here's an example :
>>  <section>
>>    <title xml:lang="en">A multilingual document</title>
>>    <title xml:lang="fr">Un site multilingue</title>
>>    <p xml:lang="en">Here's a paragraph</p>
>>    <p xml:lang="fr">Voici un paragraphe</p>
>>  <section>
>i18n transformer version of the same doc:
>  <section>
>    <title><i18n:text>A multilingual document</i18n:text></title>
>    <p><i18n:text>Here's a paragraph</i18n:text></p>
>  <section>
>Note, that you can use shorter keys instead of the text itself.

That's exacly what I'd like to avoid : the document structure is defined 
in one place, and the text in another one. Maintaining documents this 
way seems very difficult to me.

>>Note that the above couldn't have been possible with the section title
>>as an attribute (referring to the recent vote on this).
>It could be translated by the i18n transformer, though:
><section title="mydoc.title" i18n:attr="title">...</section>

Granted. But there were some comments (from Stefano, IIRC) during the 
vote explaining that titles can contain inline elements. Moreover, I 
don't think it's good to have text that gets displayed to the user 
modelled as attributes (dico keys are perfectly ok, however).

>>Building the site for a particular language will then be a simple matter
>>of filtering elements belonging to that language before formatting by a
>>language-agnostic skin.
>Yes, quite simple. I have to think if such functionality will be useful in
>i18n transformer too.
>>Any comments and criticisms are welcome.
>Just take a look at i18n samples and please tell me if it suits your needs
>or your still prefer your approach. If you choose my version than I have a
>new more advanced implementation of i18n transformer that I have no time to
>test a little more and commit.

As said above I18n transformer seems to me more suited to small 
autonomous text snippets that also can be reused in several places (e.g. 
translation of the "Cancel" button label), but inadequate to documents 
where each block appears only once.


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

View raw message