You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Corneanu Dan <cd...@savatech.ro> on 2003/08/20 14:33:46 UTC

Multilanguage sites

Hi there!

I want to build a multi language site using forrest. Here is what I am 
thinking of:
- all the content is in XML (doc-v12) format, with every file being 
translated to all the languages used.
The association between language and the content xml file is made based 
on the rule that for every
content there is a file 'foo.xml' for the default language (say EN) and 
for every other language there is a
translation 'foo(DE).xml', 'foo(FR).xml' etc.
- the 'site.xml' file will have links only to files in the default language.
- if a link like '<link site:bar>Link to bar</link>' appears in the 
'foo(DE).xml'
it must be translated to a link to the 'html' generated from file 
'bar(DE).xml'
- every page will have three links for changing the language and 
reaching the translated pages.

I have already started to play with site.xmap and document2html.xsl but 
I would really appreciate some ideas of
how can this problem be approached best. Maybe there is already some 
effort in this direction, if so please let me know.

Best regards,
Dan.


Re: Multilanguage sites

Posted by Corneanu Dan <cd...@savatech.ro>.
I have a small question about forrest/cocoon debugging/logging:

Isn't enough to set the project.debuglevel to DEBUG in the 
forrest.properties file,
in order to see all debug messages? I have spent some hours 'fighting' 
with i18n only to find that I was using an
obsolete name space: http://apache.org/cocoon/i18n/2.0 . I didn't see 
any warnings
though I have seen this line in the decompiled I18nTransformerclass:

getLogger().warn("The namespace http://apache.org/cocoon/i18n/2.0 for 
i18n is not supported any more, use: http://apache.org/cocoon/i18n/2.1");

Thanks,
Dan.


Re: Multilanguage sites

Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Corneanu Dan" <cd...@savatech.ro>
> Konstantin Piroumian wrote:
>
> >I think that i18n transformer would be very useful for menus and tabs.
And
> >it's not that difficult to plugin, just replace all the text labels
> >(elements) by:
> >
> ><i18n:text>The label in default locale</i18n:text>
> >
> >then create a dictionary directory, put translations there (e.g.
> >menu_de.xml) and then add 'i18n' transformation to the menu generation
> >pipeline.
> >
> >I'd be glad to answer your questions if you decide to go this way.
> >
> >-- Konstantin Piroumian   (kpiroumian@apache.org)
> >
> >
> Or, should I put the i18n translation keys directly in the site.xml file:
>
> <site>
>   <index href="index.html" label="index_key" i18n:attr="label"/>
>   ....
> </site>
>

Yes, this would be even better.

As for the obsolete namespace, seems that it will be changed back soon
following the discussions on Cocoon Dev list about backword compatibility. I
think that debug level for Cocoon components is specified somewhere in
WEB-INF/logkit.xconf, but I can be wrong.

Regards,
  Konstantin

>
>
>


Re: Multilanguage sites

Posted by Corneanu Dan <cd...@savatech.ro>.
Konstantin Piroumian wrote:

>I think that i18n transformer would be very useful for menus and tabs. And
>it's not that difficult to plugin, just replace all the text labels
>(elements) by:
>
><i18n:text>The label in default locale</i18n:text>
>
>then create a dictionary directory, put translations there (e.g.
>menu_de.xml) and then add 'i18n' transformation to the menu generation
>pipeline.
>
>I'd be glad to answer your questions if you decide to go this way.
>
>-- Konstantin Piroumian   (kpiroumian@apache.org)
>  
>
Or, should I put the i18n translation keys directly in the site.xml file:

<site>
  <index href="index.html" label="index_key" i18n:attr="label"/>
  ....
</site>




Re: Multilanguage sites

Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Corneanu Dan" <cd...@savatech.ro>
> Jeff Turner wrote:
>
> >How about having separate directories for each language?
> >
> >src/documentation/content/xdocs/en/*.xml
> >src/documentation/content/xdocs/de/*.xml
> >src/documentation/content/xdocs/fr/*.xml
> >...
> >
> >
> This is a good idea. There is only one thing bothering me and this is
> having multiple site.xml + tabs.xml files, one in every language folder
> (src/documentation/content/xdocs/{en|de|fr}/site.xml etc.), all having
> the same content only some labels being translated. But I think this
> could be solved by an ant script that will prepare the
> {en|de|fr}/site.xml + {en|de|fr}/tabs.xml files for every language using
> a single site.xml + tabs.xml as source (endorsed with some translation
> information), before actually running forrest.
>
> I will try the solution you proposed and see how it feels.
>
> Also in the meantime I managed to put up a solution
> based on the structure I first proposed and I'm thinking of using the
> i18n module for menus and tabs translation.

I think that i18n transformer would be very useful for menus and tabs. And
it's not that difficult to plugin, just replace all the text labels
(elements) by:

<i18n:text>The label in default locale</i18n:text>

then create a dictionary directory, put translations there (e.g.
menu_de.xml) and then add 'i18n' transformation to the menu generation
pipeline.

I'd be glad to answer your questions if you decide to go this way.

-- Konstantin Piroumian   (kpiroumian@apache.org)

>
> Dan.
>
>


Re: Multilanguage sites

Posted by Jeff Turner <je...@apache.org>.
On Mon, Aug 25, 2003 at 12:02:05PM +0300, Corneanu Dan wrote:
> Jeff Turner wrote:
> 
> >How about having separate directories for each language?
> >
> >src/documentation/content/xdocs/en/*.xml
> >src/documentation/content/xdocs/de/*.xml
> >src/documentation/content/xdocs/fr/*.xml
> >...
> > 
> >
> This is a good idea. There is only one thing bothering me and this is 
> having multiple site.xml + tabs.xml files, one in every language folder 
> (src/documentation/content/xdocs/{en|de|fr}/site.xml etc.), all having 
> the same content only some labels being translated. But I think this 
> could be solved by an ant script that will prepare the 
> {en|de|fr}/site.xml + {en|de|fr}/tabs.xml files for every language using 
> a single site.xml + tabs.xml as source (endorsed with some translation 
> information), before actually running forrest.

Instead of having multiple site.xml's, you could have one with multiple
labels:

<site>
  <index href="index.html">
    <label xml:lang="en">Index</label>
    <label xml:lang="fr">l'index</label>
    ...
  </index>

Anything is possible with some XSLT and sitemap hacking.  For example,
RDF:

<rdf:RDF
  xml:base=""
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns="http://apache.org/forrest/metadata/1.0#"
  xmlns:dc="http://purl.org/dc/elements/1.1/#">

  <folder rdf:ID="/" about=".">
    <file rdf:ID="index"
      dc:Source="index.xml"
      dc:Description="Forrest home page"
      dc:Creator="Various"
      dc:Format="text/xml"
      href="index.html">
      <dc:Title>
        <rdf:Alt>
          <rdf:li xml:lang="en">Index</rdf:li>
          <rdf:li xml:lang="de">Das Index :)</rdf:li>
        </rdf:Alt>
      </dc:Title>
    </file>
  </folder>
</rdf:RDF>


--Jeff

> 
> I will try the solution you proposed and see how it feels.
> 
> Also in the meantime I managed to put up a solution
> based on the structure I first proposed and I'm thinking of using the 
> i18n module for menus and tabs translation.
> 
> Dan.
> 

Re: Multilanguage sites

Posted by Corneanu Dan <cd...@savatech.ro>.
Jeff Turner wrote:

>How about having separate directories for each language?
>
>src/documentation/content/xdocs/en/*.xml
>src/documentation/content/xdocs/de/*.xml
>src/documentation/content/xdocs/fr/*.xml
>...
>  
>
This is a good idea. There is only one thing bothering me and this is 
having multiple site.xml + tabs.xml files, one in every language folder 
(src/documentation/content/xdocs/{en|de|fr}/site.xml etc.), all having 
the same content only some labels being translated. But I think this 
could be solved by an ant script that will prepare the 
{en|de|fr}/site.xml + {en|de|fr}/tabs.xml files for every language using 
a single site.xml + tabs.xml as source (endorsed with some translation 
information), before actually running forrest.

I will try the solution you proposed and see how it feels.

Also in the meantime I managed to put up a solution
based on the structure I first proposed and I'm thinking of using the 
i18n module for menus and tabs translation.

Dan.


Re: Multilanguage sites

Posted by Jeff Turner <je...@apache.org>.
On Wed, Aug 20, 2003 at 03:33:46PM +0300, Corneanu Dan wrote:
> Hi there!
> 
> I want to build a multi language site using forrest. Here is what I am 
> thinking of:
> - all the content is in XML (doc-v12) format, with every file being 
> translated to all the languages used.
> The association between language and the content xml file is made based 
> on the rule that for every
> content there is a file 'foo.xml' for the default language (say EN) and 
> for every other language there is a
> translation 'foo(DE).xml', 'foo(FR).xml' etc.
> - the 'site.xml' file will have links only to files in the default language.
> - if a link like '<link site:bar>Link to bar</link>' appears in the 
> 'foo(DE).xml'
> it must be translated to a link to the 'html' generated from file 
> 'bar(DE).xml'
> - every page will have three links for changing the language and 
> reaching the translated pages.

How about having separate directories for each language?

src/documentation/content/xdocs/en/*.xml
src/documentation/content/xdocs/de/*.xml
src/documentation/content/xdocs/fr/*.xml
...

I assume you'd want a separate menu for each language, so you'd need a
site.xml in each language directory.

This requires overriding and modifying menu.xmap and linkmap.xmap.

If you look in menu.xmap, you'll see site.xml is used in this snippet:

  <map:match pattern="**menulinks-*">
    <map:generate src="content/xdocs/site.xml" />

To read instead from {en,de,fr,..}/site.xml, you can change that to:

  <map:match pattern="*/**site">
    <map:generate src="content/xdocs/{1}/site.xml" />
    <map:serialize type="xml"/>
  </map:match>
  
  <map:match pattern="**menulinks-*">
    <map:generate src="cocoon:/{1}site" />

So the matcher 'call stack' for de/foo/index.html would be:

de/foo/index.html           (sitemap.xmap)
de/foo/menu-index.html      (sitemap.xmap)
de/foo/book-index.html      (menu.xmap)
de/foo/menulinks-index.html (menu.xmap)
de/foo/site                 (menu.xmap)
content/xdocs/de/site.xml   (filesystem)

So the menu for de/foo/index.html would be generated from
content/xdocs/de/site.xml


Link rewriting is similar.  If you look in sitemap.xmap's
**body-*.html pipeline, you'll see the link rewriting done with:

  <map:transform type="linkrewriter" src="cocoon:/{1}linkmap-{2}.html"/>

You'll find the definition of **linkmap-*.html in linkmap.xmap.  I
think that changing its matchers to the following will do the trick:

  <map:match pattern="en/**abs-linkmap">
    <map:generate src="content/xdocs/en/site.xml" />
    <map:transform src="resources/stylesheets/absolutize-linkmap.xsl" />
    <map:serialize type="xml" />
  </map:match>
  
  <map:match pattern="de/**abs-linkmap">
    <map:generate src="content/xdocs/de/site.xml" />
    <map:transform src="resources/stylesheets/absolutize-linkmap.xsl" />
    <map:serialize type="xml" />
  </map:match>
  
  <!-- other languages here -->
  
  <map:match pattern="**linkmap-*">
    <map:generate src="cocoon://{1}abs-linkmap" />
    <map:transform src="resources/stylesheets/relativize-linkmap.xsl">
      <map:parameter name="path" value="{1}{2}" />
      <map:parameter name="site-root" value="{conf:project-url}" />
    </map:transform>
    <map:serialize type="xml" />
  </map:match>


Experiments with sitemaps are best done interactively ('forrest run').
Any pipeline can be requested from the browser, so I'd start by trying
to get http://localhost:8888/de/menulinks-index.html working.

More info on menus & linking, and the sitemap at:

http://xml.apache.org/forrest/linking.html
http://xml.apache.org/forrest/sitemap-ref.html


--Jeff

> I have already started to play with site.xmap and document2html.xsl but 
> I would really appreciate some ideas of
> how can this problem be approached best. Maybe there is already some 
> effort in this direction, if so please let me know.
> 
> Best regards,
> Dan.
>