forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From iss...@cocoondev.org
Subject [issues] New comment: (FOR-18) support mulitple languages
Date Thu, 01 Jan 1970 00:00:00 GMT
The following comment has been added to this issue:

     Author: Ralf Hauser
    Created: Mon, 20 Jan 2003 8:05 AM
       Body:
Jeff, As a novice to XML, you mention in your referenced 021227 mailing-list post: "... doesn't
lock users into using only Forrest.  Only problem is, it assumes rather more XML knowledge
than I'd expect most doc editors would have." I am one of those who needs a simple solution
- at least to start with.

You asked for real-life examples - I will attach one next.

Re the later posts:
1) the hierarchy en-US --> en --> nothing looks good to me, but because I also want
to cater to 
1a) people who do not know how to change the locale on their PC or 
1b) who visit an internet cafe/use someone else's machine and should mess with the configuration,
this hierarchy approach wouldn't obsolete my "language-Switcher div".
Since all files along Konstantin's hierarchy have the .xml extension and are possibly self-standing,
I named my layout file .xmi (like xml include) since on its own, it will not be intelligible.
2) Maintaining parallel URI spaces looks awkward to me because the layout hopefully is redundant
for 99.9% and 
2a) the verbosity differences can hopefully be handled with proper browser rendering (e.g.
Mozilla:viewport?) 
2b) I have my "language-Switcher div" in m4 defined such that with setting a single property,
instead of letting to switch between languages, it alerts that the very page is only available
in English.
3) While I agree with Steven that it is confusing having multilingual versions handled inside
one document, I fear that the same argument will be applied to my structure of having a single
page pieced together out of a content file and a layout file among others. My counter-argument
would be:
3a) Thanks to cocoon, despite not being WYSIWYG, a simple reload on localhost:8888 lets one
instantly experience the effect of changes to any of the files undertaken
3b) an ant-like up-to-date mechanism could at least help the editors to keep translations
"in sync":
When a .en.xmi is newer (assuming english is the master version), the .de.xml, .fr.xml, .??.xml
will get a warning <echo>.
Obviously such a warning can be avoided by a simple "touch" command, but a reasonable editor
wouldn't do that. Sure - this obviously doesn't ensure that the translations are semantically
identical, but at least, it will become very obvious, if after adding an addition $text_n+1,
this variable name instead of some additional text becomes visible in for example the de.html
- then most likely, the editor forgot to update the .de.xml content-wise!
---------------------------------------------------------------------
View the issue:

  http://issues.cocoondev.org/jira//secure/ViewIssue.jspa?key=FOR-18


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: FOR-18
    Summary: support mulitple languages
       Type: New Feature

     Status: Unassigned
   Priority: Critical

    Project: Forrest
  Component: None

   Assignee: 
   Reporter: Ralf Hauser

    Created: Sat, 11 Jan 2003 2:27 AM
    Updated: Sat, 11 Jan 2003 2:27 AM

Description:
In my current environment to develop static mulitlingual web-sites, I use an ant build.xml
and the m4 macro preprocessor to achieve the following (sample):
1) index.en.m4 gets converted to index.en.html
The *.en.m4 contains all language dependent text (similarly *.de.m4 for German) and includes
index.m4 that contains the page's content layout.
[(^\.)+].m4 includes sitedef.m4 where I define all global parts of the website (e.g. navigation
structure, unique content e.g. phone numbers, filenames, etc.). This in turn includes a sitedefs.en
or sitedef.de, ... respectively for global, language dependent definitions.
2) Dependencies 
a) upon change of [(^\.)+].m4, all depending *.*LANG*.html get rebuilt
b) upon change of sitedef.m4, build.xml, and alike all *.html gets rebuilt
c) upon change of sitedefs.en all *.en.html get rebuilt.

Obviously, I could use the exact same approach to create .xml whereever I created .html before,
but my long-term goal is to get rid of m4. Has anybody already put some thought into how this
would be done with forrest?


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.cocoondev.org/jira//Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message