A while ago we did have a discussion about the different means of localizing
an application. The two major approaches are: dynamic during runtime (Chris
is working on) and static, with static meaning pre-processed local specific
markup like e.g. test_de_DE.html. Both approaches have there specific
advantages and disadvantages and none is always the perfect solution. I
started gathering some requirements which I'd like to share with you as well
as an idea on how to implement them (I'm not very good at theoretically
designing apps, I need to underline my ideas with prototypes).
One of the disadvantages of the static approach is that you need to keep 10+
markup files in sync, which is almost impossible without a tool. A tool like
a pre-processor taking the only true source of the markup containing
placeholders for text to be localized and which generates the *_de_DE.html
files taking the localized text from some external source.
Thus the requirements are:
1) It must be easily possible to retrieve localized text from any data
source
(e.g. properties files, database, excel, etc.) to generate the 10+
localized
files. This is to support external translator offices, which can not
deal with HTML markup.
2) It must be possible to create the HTML with any HTML editor and the
markup preview must not include any ${variable} or the like. The markup
shall not require any visible tags, attributes or text. WYSIWYG.
That is, it must be like Wicket.
3) The solution must be agnostic against changes to the structure of the
markup. That is, adding some tag or moving tags or attributes shall not
require modifications to the source containing the localized text (the
key).
Thus, the key must not depend on the HTML structure.
4) The solution must support styles <name><locale><style>.html
5) The solution must support languages like arabic, where the screen layout
may be completly different.
6) The solution must support development during which the localized text
may change very often. Thus automatic re-processing shall be supported.
7) It must be possible to localize tag bodies as well as tag attributes
(<input value="")
8) Optional: The span tag surrounding the localized text must be removeable
(configurable), only printing the tag body (the localized text) into the
output file.
Solutions which came into my mind:
XSLT: I personally don't like XSLT. I still struggle with its concept.
Thus
I regard it to be complicated and Wicket is about making thinks easy
and
not complicated.
Template engines like Velocity or Freemarker provide support for
variables. These
variables might be loaded by the localized text provider. However they
both
don't meet requirement 1. Variables ${variable} are visible while
creating
the HTML page and it won't be WYSIWYG anymore.
Wicket's markup approach using span tags for labels though is
none-intrusiv
and does meet requirement 2. By means of another componentName instead
of
wcn, e.g. w18n could be used and thus separating the two stages:
pre-processing and Wicket. The pre-processor only processing
w18n components and leaving wcn components untouched.
The next problem to be solved was about how to address the w18n components.
How shall the key used to address the localized text look like. In order to
meet
requirements 3 and 5, I decided to go for a flat structure. That is, no
component hierachy like Wicket, though names might include dots
(pre-processing
won't used OGNL or JavaBeans. Keys would just be strings.)
It is up to the provider to meet requirement 4. With properties files e.g.
the
file name may contain the locale (e.g. _DE_de) and may contain the style as
well
(as Wicket does).
To meet requirement 6 I have two solutions in mind. First is by means of a
subclass of WebApplication which could be used as base class.
W18nApplication registers a Watcher for each properties file and creates a
new HTML markup in case it or the HTML template has been changed. Second: an
Ant and Maven task which run the pre-processor for each modified properties
files or html template markup file.
Examples:
<span id="w18n-firstname">Firstname</span>
<span w18n="firstname"/>Firstname</span>
Allowed as well and not using OGNL
<span id="w18n-packageA.moduleB.firstname"/>Firstname</span>
Allowed as well, though I've no use case
<span id="w18n-wcn-firstname"/>Firstname</span>
Tag attributes must be localized as well
<input id="w18n-inputValue" type="submit" value="localized Text"/>
The localized text (e.g. from properties) may include any valid HTML markup.
E.g.
headline=This is <strong>bold</strong> or
href=Please visit <a href="http://wicket.sourceforge.net";>Wicket</a> for
more details
href=Please visit <a href="http://wicket.sourceforge.net";><span
id="wcn-dynText">dynamically localized</span></a> for more details
com.myapp.test.title=Keys may include dots. They are not OGNL interpreted
This is how tag attributes are to be addressed
[EMAIL PROTECTED]
By means of the @attributeName syntax, any attribute's value may be
localized. Attributes such as <input value= text= (tooltips) >
As I mentioned above, I'm not very good at theoretically thinking a solution
100% through. Thus I started implementing these ideas and it was amazingly
easy as Wicket core and the Mock implementations already provided most of
the required functionality. I now have a working prototype incl. a pluggable
properties-files provider. What is missing are the Ant and Maven tasks and a
utility class using the Watcher to automatically re-process the file.
Open issue: Because the pre-processor is using the mock classes which are
currently part of Wickets test environment, and because the test classes are
NOT being loaded into wicket.jar, the pre-processor is maintaing it's own
copies of the mock classes, which is not a good solution. On the other hand,
we can not move the mock classes into another package, because they need
access to "standard" (not public, protected or privat) protected Wickets
core classes. Moving it straight into the core is probably not a good
solution as well.
Open issue: Assuming your application requires dynamic as well as static
localization, the properties files would clash or they need to contain
static as well as dynamic texts. Though this sounds good at first, the
pre-processor would no longer be able to validate that the properties files
contains the all the keys and only the required keys, required for the
markup.
Open issue: Assuming the markup is test.html and assuming the markup of your
default language shall not include the <span w18n=> tags (shall include the
body text only), than you need to pre-process the default markup files as
well. There are two issue now: a) you need a properties file with the
default language texts and b) the source markup file and destination markup
file have the same name. Obviously pre-processing will overwrite the
original source markup file. That is a problem and I'venot yet an idee on
how to fix that. I already thought about something like *-w18n.html for the
original source markup, but I'm sure this is a good approach.
Open issue: I'm not sure about necessary conversions of charsets: read from
properties files and write in html (xml).
Now, what do you think about it? In case there is a general interest, I'd
contrib it to the project, though not knowing where to place it. Into the
core? Into Examples or into a separate directory? Any suggestions on the
open issues?
Regards
Juergen
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Wicket-develop mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
