You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Piroumian, Konstantin" <KP...@flagship.ru> on 2001/06/01 10:18:40 UTC
New I18nTransformer
> > There are some features and changes that I was planning to implement,
but
> > now I am a little busy with other work. Shortly, here are they:
> >
> > 1. Date i18n (<i18n:date src-format="dd:MM:yyyy" format="dd-MMM-yy"
> > value="11:01:2001" />)
> > 2. Number i18n (<i18n:number format="#,##" value="10.4" />)
> > 3. Multiple dictionary support (configured from sitemap)
> > 4. Dictionary inclusions (<i18n:dictionary href="dict.xml" [lang="ru"]/>
> >
> > Some other improvements, such as dictionary caching etc.
> > Maybe I forgot something...
>
> All sound good. I have a couple of ideas as well that I was thinking
> of working on, they may sound a little too diverse though, hence why I
> was asking what your initial intentions were.
>
> Here they are, I'm intrerested in what you think about them:
>
> o selection of language based on request value
>
> currently language selection is done via the lang cgi
> parameter. It's possible to find this out automatically from the
> request object what language the user wants with the request.
>
> One option would be to use the lang value if it exists, otherwise to
> get this value from the request object automatically. This lets us
> have both sets of functionality.
I've implemented such functionality in the LangSelect action, which is used
in I18nTransformer2 to choose the language. Session and cookie language
selection are also supported. Now you can configure your LangSelect action
to use request, session or a cookie to save the current language. Although I
didn't tested it and it's not in C2 distro yet.
I think today I'll post it to cocoon-dev a little later.
>
> o handling of country code and variants
>
> Is this currently handled by the lang cgi-param ? The reason I ask is
> because in some domains the country code is important.
> eg. en_US != en_GB
Yes, I am quite agree with you and also added a Locale attribute to
transformer, which is now used only to set the MessageFormat class's locale
(but in fact, it doesn't affect on substitutions without special format,
such as date or number. See: java.text.MessageFormat).
>
> o translated text in separate files ?
>
> with large applications and multiple languages, the dictionary file
> could become quite large. I thought about splitting the data up into
> different files, separated by language/country/variant code.
>
> this also lets us send off catalogue files for translations by
> translator departments like what we have here in Dresdner Bank. Having
> everything all in one file makes this difficult to do.
Again agree. I ment exactly the same thing when talked about multiple
dictionary support.
I also can envision some utility tool for dictionary template generation
from the source with the given language. I mean:
somewhere in source file:
...
<i18n:text i18n:key="a_key" />
...
run that tool with lang="ru" command line param and get this in a dictionary
file:
<entry>
<key>a_key</key>
<translation lang="ru"></translation>
</entry>
So, you can keep your dictionaries up-to-date and easily can add a new
language.
>
> o numbers ? (is that localisation ?)
Yes, because not only the format changes, but the digits themselves can
differ depending on the locale (Western, Arabic, Indian).
>
> I like your idea to format numbers as well. If we can use the locale
> information from the request it would be even better too.
>
> eg. the number 20000 is written like so with the following locales:
> en_GB = 20,000
> de_DE = 20.000
>
> for the same number. Java can already do this conversion via its
> numberformat classes.
Sure. I was going to use exactly that class :)
>
> o automatic identification of available languages,
>
> Java has a method of automatic finding property files that match the
> current locale based on a naming convention. There is also an
> XMLResourceBundle class in the avalon scratchboard which does the same
> and would let us locate xml catalogue files dynamically by locale
> instead of explicit 'src' name.
That is a good idea. Didn't think of that. I'll look at that classes.
>
> o default value when selected langauge key is not available.
>
> This would be a default value to be used when no translated value for
> a particular key for the particular language is available
> (ie. 'NOT TRANSLATED'). This would help recover errors if the
> catalogue files were split up and not held all together.
This must be configurable, I think.
I've added log warning if translation not found. Currently, you can specify
a default value like this:
<i18n:text i18n:key="a_key">NOT TRANSLATED</i18n:text>
Wouldn't it be enough?
>
> That's it so far.
>
> I'm interested in your thoughts about the above ideas - perhaps we
> should also take this discussion to the cocoon2 dev list as well ?
Sure. But now I think they are all busy with the Beta and there is no much
interest to i18n.
>
> I'm not sure if my ideas are too diverse from what your initial
> thoughts were - if so, then perhaps this warrants a 3rd i18n
> transformer ? This is something I'd like to avoid, but I'll respect
> your wishes there, if my ideas contradict yours.
As I see, we have no contradicting ideas, so we can move in the same
direction.
How do you feel about separating the work like this:
me: implement number and date support
you: implement multiple dictionary support
I have some more ideas, but I can't imagine myself how it can be implemented
in a good way. They are:
1. Using XML elements in substitution text and params, e.g.:
<i18n:translate>
<i18n:text>See {0} for detailes</i18n:text>
<i18n:param><a
href="i18n.html"><i18n:text>documentaion</i18n:text></a></i18n:param>
</i18n:translate>
2. Using java object in params:
<i18n:translate>
<i18n:text>Today is: {0, date, 'dd-MMM-yyyy'}</i18n:text>
<i18n:param>new Date()</i18n:param>
<!-- or maybe something like this:
<i18n:param type="date" src="java:new Date()" />
-->
</i18n:translate>
3. Named params:
<i18n:translate>
<i18n:text>Current user is: {username}</i18n:text>
<i18n:param
name="username"><xsp:expr>request.getUser()<xsp:expr></i18n:param>
</i18n:translate>
Unfortunately, our project management decided to turn to JSP and there is no
interest in i18n with XSP and transformer, so work on I18nTransformer out of
my current work and it's very exhausting.
> Cheers,
>
> Marcus
Regards,
Konstantin Piroumian.
P.S. I posted a copy of this message to cocoon-dev. Maybe somebody else will
share his ideas.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: New I18nTransformer
Posted by Gerd Mueller <ge...@smb-tec.com>.
> > > now I am a little busy with other work. Shortly, here are they:
> > >
> > > 1. Date i18n (<i18n:date src-format="dd:MM:yyyy" format="dd-MMM-yy"
> > > value="11:01:2001" />)
> > > 2. Number i18n (<i18n:number format="#,##" value="10.4" />)
> > > 3. Multiple dictionary support (configured from sitemap)
> > > 4. Dictionary inclusions (<i18n:dictionary href="dict.xml"
> > > [lang="ru"]/>
Here I would suggest the XSL like inclusion <import>/<include> to handle
double entries in dictionaries.
Best Regards,
Gerd
--
______________________________________________________________________
Gerd Mueller mailto:gerd@smb-tec.com
SMB GmbH http://www.smb-tec.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: New I18nTransformer
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> This is fine with me. Can you please send in the latest patches you
> mentioned so that we are both working from the most up to date source.
>
> I'll apply your patches, and start having a look at multiple
> dictionary support. I'm sure we'll talk more over the next few days..
> (or even hours! :-) )
I've posted a patch to cocoon-dev with the latest updates.
Also, for your convenience I send you the latest source files and a sample
sitemap.
>
> Cheers,
>
> Marcus
Kot.
Re: New I18nTransformer
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Konstantin!
Great to read your input. Thanks for your comments.
On Fri, 1 Jun 2001, Piroumian, Konstantin wrote:
> > I'm not sure if my ideas are too diverse from what your initial
> > thoughts were - if so, then perhaps this warrants a 3rd i18n
> > transformer ? This is something I'd like to avoid, but I'll respect
> > your wishes there, if my ideas contradict yours.
>
> As I see, we have no contradicting ideas, so we can move in the same
> direction.
> How do you feel about separating the work like this:
> me: implement number and date support
> you: implement multiple dictionary support
This is fine with me. Can you please send in the latest patches you
mentioned so that we are both working from the most up to date source.
I'll apply your patches, and start having a look at multiple
dictionary support. I'm sure we'll talk more over the next few days..
(or even hours! :-) )
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&: After Hours : +49 69 49086750
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org