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 2002/01/24 10:26:28 UTC
i18n transformer update
Hi, C2ers!
As I have a little free time, I'm going to make some code clean up in i18n
transformer and LocaleAction. I've already added JavaDoc comments to all
public members and polished a little class comments.
Next I am going to create an I18nUtils class that will contain all general
purpose i18n routines, such as locale string parsing, date/number formatting
and parsing, etc. Currently, it will be placed in org.apache.cocoon.i18n
package.
Also, I'm going to add a new <i18n:get-locale> element that will use
LocaleAction.getLocale() to return the current selected Locale (it can be
different from request.getLocale()). (It'd be good also to move getLocale()
to the new I18nUtils, but now getLocale() has a lot of dependencies from
Cocoon, but I want to keep I18nUtils as much general as possible).
Are there any other wishes/suggestions/comments regarding i18n?
Best regards,
Konstantin Piroumian
Leading Software Developer
Protek Flagship LLC
Phone: + 7 095 795 0520 (add. 1288)
Fax: + 7 095 795 0525
E-mail: kpiroumian@flagship.ru
http://www.protek.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: i18n transformer update
Posted by Enke Michael <Mi...@wincor-nixdorf.com>.
"Piroumian, Konstantin" wrote:
> ...
> > 1) I have a whish: Could we introduce a new cocoon.xconf parameter for i18n
> > called empty-translation, e.g. empty-translation="."?
>
> Do you mean sitemap.xmap?
Doesn't matter. I'm not so deep in the internals to know what to
configure in cocoon.xconf or sitemap.xmap.
> > At this time it is not possible to have an empty translation.
> > I need this for generic formular creation and I only commented out
> > line 357 in XMLResourceBundle.java: itemValue = itemValue.trim();
> > and put a space in the dictionary.
> > But I think a more common solution would be fine also for others.
>
> Ok, I'll take a look at it. As I can see, you can now use
> 'untranslated-text' param to provide custom text for not found messages.
> Maybe this can be the common solution for your case?
No, we must differentiate the cases that either a translation was really forgotten
or a <i18n:text>somethink</i18n:text> should result in silence.
For me the "somethink" comes out of a database. I have a formular.xsp
which creates textfields and descriptions for the textfields.
The textfields are correlated with tablecolumn names, e.g. "Employee Number".
Another column in formular table is called "relation", this can be
"<=", "=" or ">=". So both columns together are responsible to create
textfields "From Employee Number" or "To Employee Number".
In the case of equality ("Employee name") I want to have an empty translation for "=".
> > 2) I prepared 2 new attributes: currency-no-unit and int-currency-no-unit
> > This prevents the "$" or "DM" (now "Euro") from printing.
> > I append the diff -u
>
> Are you sure? As I could get from the diff you just set the number of
> fraction digits and nothing else. Anyway, this can be useful.
No. Look closely, there is a NumberFormat.getInstance(),
not a NumberFormat.getCurrencyInstance().
And than the fractions of that NumberFormat-Instance are set as from
currencyInstance.
> Btw, do we need separate 'type' and 'sub-type' attributes? It's absolutely
> enough to have 'type' = [number, date, date-time, time, currency, percent].
I agree!
> We can introduce new attributes: 'max-fraction' and 'min-fraction'.
No, that is not the way.
Java knows how many fractions are necessary for money values of the used locale.
This is not always 2. So Italy or Spain had (before the Euro) no fraction digits.
> ...
Regards,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: i18n transformer update
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> Hi Konstantin,
> that is fine that you have a little time ;-)
Unfortunately, only two days. I don't use Cocoon in any project, that's why
I can't do much for it now.
>
> 1) I have a whish: Could we introduce a new cocoon.xconf parameter for
i18n
> called empty-translation, e.g. empty-translation="."?
Do you mean sitemap.xmap?
> At this time it is not possible to have an empty translation.
> I need this for generic formular creation and I only commented out
> line 357 in XMLResourceBundle.java: itemValue = itemValue.trim();
> and put a space in the dictionary.
> But I think a more common solution would be fine also for others.
Ok, I'll take a look at it. As I can see, you can now use
'untranslated-text' param to provide custom text for not found messages.
Maybe this can be the common solution for your case?
> 2) I prepared 2 new attributes: currency-no-unit and int-currency-no-unit
> This prevents the "$" or "DM" (now "Euro") from printing.
> I append the diff -u
Are you sure? As I could get from the diff you just set the number of
fraction digits and nothing else. Anyway, this can be useful.
Btw, do we need separate 'type' and 'sub-type' attributes? It's absolutely
enough to have 'type' = [number, date, date-time, time, currency, percent].
We can introduce new attributes: 'max-fraction' and 'min-fraction'.
> 3) Since the last update (?) of XMLResourceBundleFactory.java I get this
note
> at compile time:
> Note: .../i18n/XMLResourceBundleFactory.java uses or overrides a
deprecated API. Recompile with "-deprecation" for details.
> If you could have a look at this ...
As I've told in my previous mail, i18n classes can be out of date now.
Regards,
Konstantin Piroumian
>
> Thanks,
> Michael
>
>
> "Piroumian, Konstantin" wrote:
> >
> > Hi, C2ers!
> >
> > As I have a little free time, I'm going to make some code clean up in
i18n
> > transformer and LocaleAction. I've already added JavaDoc comments to all
> > public members and polished a little class comments.
> >
> > Next I am going to create an I18nUtils class that will contain all
general
> > purpose i18n routines, such as locale string parsing, date/number
formatting
> > and parsing, etc. Currently, it will be placed in org.apache.cocoon.i18n
> > package.
> >
> > Also, I'm going to add a new <i18n:get-locale> element that will use
> > LocaleAction.getLocale() to return the current selected Locale (it can
be
> > different from request.getLocale()). (It'd be good also to move
getLocale()
> > to the new I18nUtils, but now getLocale() has a lot of dependencies from
> > Cocoon, but I want to keep I18nUtils as much general as possible).
> >
> > Are there any other wishes/suggestions/comments regarding i18n?
> >
> > Best regards,
> >
> > Konstantin Piroumian
> > Leading Software Developer
> >
> > Protek Flagship LLC
> > Phone: + 7 095 795 0520 (add. 1288)
> > Fax: + 7 095 795 0525
> > E-mail: kpiroumian@flagship.ru
> > http://www.protek.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
----------------------------------------------------------------------------
----
> --- I18nTransformer.java.orig Thu Jan 24 12:53:01 2002
> +++ I18nTransformer.java Thu Jan 24 12:53:04 2002
> @@ -1110,6 +1110,19 @@
> int_currency = 1;
> for ( int i = 0; i < to_fmt.getMaximumFractionDigits(); i++ )
> int_currency *= 10;
> + } else if ( subType.equals( "currency-no-unit" ) ) {
> + DecimalFormat tmp = (DecimalFormat)
NumberFormat.getCurrencyInstance( loc );
> + to_fmt = (DecimalFormat) NumberFormat.getInstance( loc );
> +
to_fmt.setMinimumFractionDigits(tmp.getMinimumFractionDigits());
> +
to_fmt.setMaximumFractionDigits(tmp.getMaximumFractionDigits());
> + } else if ( subType.equals( "int-currency-no-unit" ) ) {
> + DecimalFormat tmp = (DecimalFormat)
NumberFormat.getCurrencyInstance( loc );
> + int_currency = 1;
> + for ( int i = 0; i < tmp.getMaximumFractionDigits(); i++ )
> + int_currency *= 10;
> + to_fmt = (DecimalFormat) NumberFormat.getInstance( loc );
> +
to_fmt.setMinimumFractionDigits(tmp.getMinimumFractionDigits());
> +
to_fmt.setMaximumFractionDigits(tmp.getMaximumFractionDigits());
> } else if ( subType.equals( "percent" ) ) {
> to_fmt = (DecimalFormat) NumberFormat.getPercentInstance(
loc );
> }
>
>
----------------------------------------------------------------------------
----
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: i18n transformer update
Posted by Enke Michael <Mi...@wincor-nixdorf.com>.
Hi Konstantin,
that is fine that you have a little time ;-)
1) I have a whish: Could we introduce a new cocoon.xconf parameter for i18n
called empty-translation, e.g. empty-translation="."?
At this time it is not possible to have an empty translation.
I need this for generic formular creation and I only commented out
line 357 in XMLResourceBundle.java: itemValue = itemValue.trim();
and put a space in the dictionary.
But I think a more common solution would be fine also for others.
2) I prepared 2 new attributes: currency-no-unit and int-currency-no-unit
This prevents the "$" or "DM" (now "Euro") from printing.
I append the diff -u
3) Since the last update (?) of XMLResourceBundleFactory.java I get this note
at compile time:
Note: .../i18n/XMLResourceBundleFactory.java uses or overrides a deprecated API. Recompile with "-deprecation" for details.
If you could have a look at this ...
Thanks,
Michael
"Piroumian, Konstantin" wrote:
>
> Hi, C2ers!
>
> As I have a little free time, I'm going to make some code clean up in i18n
> transformer and LocaleAction. I've already added JavaDoc comments to all
> public members and polished a little class comments.
>
> Next I am going to create an I18nUtils class that will contain all general
> purpose i18n routines, such as locale string parsing, date/number formatting
> and parsing, etc. Currently, it will be placed in org.apache.cocoon.i18n
> package.
>
> Also, I'm going to add a new <i18n:get-locale> element that will use
> LocaleAction.getLocale() to return the current selected Locale (it can be
> different from request.getLocale()). (It'd be good also to move getLocale()
> to the new I18nUtils, but now getLocale() has a lot of dependencies from
> Cocoon, but I want to keep I18nUtils as much general as possible).
>
> Are there any other wishes/suggestions/comments regarding i18n?
>
> Best regards,
>
> Konstantin Piroumian
> Leading Software Developer
>
> Protek Flagship LLC
> Phone: + 7 095 795 0520 (add. 1288)
> Fax: + 7 095 795 0525
> E-mail: kpiroumian@flagship.ru
> http://www.protek.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: i18n transformer update
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> Peter Royal wrote:
> >
> > On Thursday 24 January 2002 06:48 am, Sylvain Wallez wrote:
> > > I also had a look at the key lookup stuff (including
XMLResourceBundle),
> > > and it seems to me it is really performance-killing. Since I also need
> > > pluggable sources for translations, I will take this subject if you
> > > don't mind.
> >
> > Yes, the i18nTransformer is easily the slowest component in our pipeline
> > here. Things were much better after I made it Cacheable, though.
> >
>
> Also the amount of debug output is not necessary and slows it down alot.
I'll remove all unnecessary messages.
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: i18n transformer update
Posted by Enke Michael <Mi...@wincor-nixdorf.com>.
Peter Royal wrote:
>
> On Thursday 24 January 2002 06:48 am, Sylvain Wallez wrote:
> > I also had a look at the key lookup stuff (including XMLResourceBundle),
> > and it seems to me it is really performance-killing. Since I also need
> > pluggable sources for translations, I will take this subject if you
> > don't mind.
>
> Yes, the i18nTransformer is easily the slowest component in our pipeline
> here. Things were much better after I made it Cacheable, though.
>
Also the amount of debug output is not necessary and slows it down alot.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: i18n transformer update
Posted by Peter Royal <pr...@managingpartners.com>.
On Thursday 24 January 2002 06:48 am, Sylvain Wallez wrote:
> I also had a look at the key lookup stuff (including XMLResourceBundle),
> and it seems to me it is really performance-killing. Since I also need
> pluggable sources for translations, I will take this subject if you
> don't mind.
Yes, the i18nTransformer is easily the slowest component in our pipeline
here. Things were much better after I made it Cacheable, though.
I can understand that abstractness of the XMLResourceBundle, but for the
i18nTransformer, all it really needs is a key->value lookup. Investigating
how to speed it up is on my list of things to do, but its not that close to
the top.
-pete
--
peter royal -> proyal@managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: i18n transformer update
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> >><snip/>
> So, what about the following changes :
> - remove the configuration stuff related to _sitemap_ variable names, as
> it has no added value [is someone using names other than the default ones
?]
> - add a configuration for the name of the _request_ parameter for the
> locale, with the default to "cocoon-locale".
I've just took a look at the LocaleAction.getLocale(). It uses
'locale-attribute' exactly as you and me were expecting - it uses its value
to store request, session attributes and as the cookie name. Look at the
lines: 253, 268 and 282.
The default value is specified by the LOCALE constant and of course it can
be changed to 'cocoon-locale'.
Konstantin
>
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: i18n transformer update
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Piroumian, Konstantin wrote:
>><snip/>
>>
>>>>>Request object wraps HttpServletRequest and returns the locale that the
>>>>>user has selected in his browser, but that locale can be different from the
>>>>>one that the system supports. I don't know if any browser can set a new
>>>>>value to the http header that indicates the user locale. IMO, it's better to
>>>>>leave Request object as it is now and have a helper class that will perform
>>>>>custom language selection.
>>>>>
>>>>That's really because environment.Request is an interface that what I
>>>>propose is possible : determination of the locale can be interposed in
>>>>the wrapper before actually calling HttpServletRequest.getLocale(). This
>>>>has nothing to do with tweaking the browser's header or
>>>>HttpServletRequest which BTW is not possible
>>>>
>>>But what if somebody will need the original user locale?
>>>
>>I knew this question would come ;)
>>
>>So what about Request.getBrowserLocale() ? This way, request.getLocale()
>>give access to the locale as defined by the application (using
>>LocaleAction or other means) and getBrowserLocale() gives access to the
>>raw locale sent by the browser.
>>
>>Note that if no locale was set by the application, getLocale() should
>>fall back calling getBrowserLocale().
>>
>I don't like the idea of overriding the expected behavior of
>Request.getLocale(). Most of the people expect that it will return that same
>value as the HttpServletRequest. Maybe do the opposite thing: add
>Request.getAppLocale() and setAppLocale() or better getUserLocale() and
>setUserLocale()?
>
Mmmmh... ||I consider that the contract for request.getLocale() is to
return the locale to be used to answer the request ? This definition
doesn't make any assumption on where this locale comes from (remember
that Cocoon's environment, even if similar, is abstracted from servlets,
and even in servlets, the @return tag for getLocale() is "the preferred
|Locale| for the client").
If people use this request.getLocale(), it is because they want to
provide localized content. If two components used to produce a page use
respectively request.getLocale() and request.getUserLocale(), it is
likely you will obtain a mixed-language result !
Allowing to change the value returned by request.getLocale() means that
the application-defined locale is handled in a nearly transparent manner
(just add LocaleAction in the sitemap).
Now who uses getBrowserLocale() ? IMO, it is limited to some
user-settings page where we want to display things like "You have set
your preferred language to chinese, but your browser is configured for
brazilian".
>Are there any other opinions on this?
>
Yes, team, as it means some changes to environment.Request, what do you
think ?
<snip/>
>>What do you mean by "i18n requests" ? Requests that use the i18n
>>transformer ? Then LocaleAction will be a top-level element in my
>>sitemaps :)
>>
>Good idea! I've always thought on why it's not possible to have global
>actions or at least pipeline actions :)
>
That was an arbitrary restriction that was recently removed. Now you can
have a top-level action.
<snip/>
>>>>>>Yes : use the "cocoon-" prefix for the "locale" request parameters, as
>>>>>>for "cocoon-view" and "cocoon-action", to avoid potential naming
>>>>>>conflicts
>>>>>>
>>>>>'locale' parameters are configured in sitemap, so you can use any name
>>>>>for them (e.g.: 'locale-attribute" config param)
>>>>>
>>>>Ah, sorry, didn't notice that. But wouldn't it be better to default to
>>>>"cocoon-locale" ?
>>>>
>>>Have nothing against it. +0
>>>
>>I thinks there's a misunderstanding here : I was talking about the
>>_request_ parameter and not the _sitemap_ parameter returned by
>>LocaleAction. From what I can see, the _request_ parameter name is
>>hardcoded to "locale" in getLocale().
>>
>I understood you correctly, but the implementation were different from what
>I was expecting.
>
>>Also, I don't see a real need to configure the name of sitemap
>>parameters returned by LocaleAction since there is no possibility of
>>naming conflict, since the sitemap component is unambiguously defined by
>>the number of '../' in attribute values.
>>
>Absolutely agree. That was my proposal to have i18n attribute name
>configuration parameter, but the implementation were made not by me and it
>is not what I was thinking about.
>
>Konstantin
>
So, what about the following changes :
- remove the configuration stuff related to _sitemap_ variable names, as
it has no added value [is someone using names other than the default ones ?]
- add a configuration for the name of the _request_ parameter for the
locale, with the default to "cocoon-locale".
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: i18n transformer update
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> <snip/>
>
> >>>Request object wraps HttpServletRequest and returns the locale that the
user
> >>>has selected in his browser, but that locale can be different from the
one
> >>>that the system supports. I don't know if any browser can set a new
value to
> >>>the http header that indicates the user locale. IMO, it's better to
leave
> >>>Request object as it is now and have a helper class that will perform
> >>>custom language selection.
> >>>
> >>That's really because environment.Request is an interface that what I
> >>propose is possible : determination of the locale can be interposed in
> >>the wrapper before actually calling HttpServletRequest.getLocale(). This
> >>has nothing to do with tweaking the browser's header or
> >>HttpServletRequest which BTW is not possible
> >>
> >
> >But what if somebody will need the original user locale?
> >
> I knew this question would come ;)
>
> So what about Request.getBrowserLocale() ? This way, request.getLocale()
> give access to the locale as defined by the application (using
> LocaleAction or other means) and getBrowserLocale() gives access to the
> raw locale sent by the browser.
>
> Note that if no locale was set by the application, getLocale() should
> fall back calling getRawLocale().
I don't like the idea of overriding the expected behavior of
Request.getLocale(). Most of the people expect that it will return that same
value as the HttpServletRequest. Maybe do the opposite thing: add
Request.getAppLocale() and setAppLocale() or better getUserLocale() and
setUserLocale()?
Are there any other opinions on this?
>
> >>>Maybe it'll be better to pass selected locale externaly it to the
> >>>transformer in the sitemap? This way we can use any locale
> >>>selection/determination mechanism and have transformer that don't
depend
> >>>on an action.
> >>>
> >>>
> >>> <map:match pattern="*.xml">
> >>> <map:action name="locale-select">
> >>> <map:generate src="{1}.xml"/>
> >>> <map:transform type="i18n">
> >>> <map:parameter name="locale" value="{cocoon-locale}" />
> >>> </map:transform>
> >>> <map:transform src="simple.xsl"/>
> >>> <map:serialize/>
> >>> </map:action>
> >>> </map:match>
> >>>
> >>>What about this?
> >>>
> >>I goes in the direction of what I want to avoid : multiple sources to
> >>get the locale ;)
> >>
> >
> >You can setup a matcher for all i18n requests and have single source -
> >LocaleAction.
> >
> What do you mean by "i18n requests" ? Requests that use the i18n
> transformer ? Then LocaleAction will be a top-level element in my
> sitemaps :)
Good idea! I've always thought on why it's not possible to have global
actions or at least pipeline actions :)
>
> >>However, pluggable mechanism is possible with my second proposal :
> >>adding Request.setLocale(). This method can be called by whatever
> >>mechanism you want.
> >>
> >
> >So, you'll need an action to call it - we are back to the LocaleAction ;)
> >
> Sure. But if LocaleAction changes the locale returned by
> request.getLocale(), this value is then globally available, thus
> avoiding the need for <map:parameter name="locale" .../>
Yes, that's true
>
> >>>>>Are there any other wishes/suggestions/comments regarding i18n?
> >>>>>
> >>>>Yes : use the "cocoon-" prefix for the "locale" request parameters, as
> >>>>for "cocoon-view" and "cocoon-action", to avoid potential naming
conflicts,
> >>>>
> >>>'locale' parameters are configured in sitemap, so you can use any name
> >>>for them (e.g.: 'locale-attribute" config param)
> >>>
> >>Ah, sorry, didn't notice that. But wouldn't it be better to default to
> >>"cocoon-locale" ?
> >>
> >
> >Have nothing against it. +0
> >
> I thinks there's a misunderstanding here : I was talking about the
> _request_ parameter and not the _sitemap_ parameter returned by
> LocaleAction. From what I can see, the _request_ parameter name is
> hardcoded to "locale" in getLocale().
I understood you correctly, but the implementation were different from what
I was expecting.
>
> Also, I don't see a real need to configure the name of sitemap
> parameters returned by LocaleAction since there is no possibility of
> naming conflict, since the sitemap component is unambiguously defined by
> the number of '../' in attribute values.
Absolutely agree. That was my proposal to have i18n attribute name
configuration parameter, but the implementation were made not by me and it
is not what I was thinking about.
Konstantin
>
> >So, maybe you'd start from LocaleAction (or Request interface) until I'll
> >send my latest version of i18n transformer?
> >
> Please go on, as I don't have much time for this now.
>
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: i18n transformer update
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Piroumian, Konstantin wrote:
<snip/>
>>>Request object wraps HttpServletRequest and returns the locale that the user
>>>has selected in his browser, but that locale can be different from the one
>>>that the system supports. I don't know if any browser can set a new value to
>>>the http header that indicates the user locale. IMO, it's better to leave
>>>Request object as it is now and have a helper class that will perform
>>>custom language selection.
>>>
>>That's really because environment.Request is an interface that what I
>>propose is possible : determination of the locale can be interposed in
>>the wrapper before actually calling HttpServletRequest.getLocale(). This
>>has nothing to do with tweaking the browser's header or
>>HttpServletRequest which BTW is not possible
>>
>
>But what if somebody will need the original user locale?
>
I knew this question would come ;)
So what about Request.getBrowserLocale() ? This way, request.getLocale()
give access to the locale as defined by the application (using
LocaleAction or other means) and getBrowserLocale() gives access to the
raw locale sent by the browser.
Note that if no locale was set by the application, getLocale() should
fall back calling getRawLocale().
>>>Maybe it'll be better to pass selected locale externaly it to the
>>>transformer in the sitemap? This way we can use any locale
>>>selection/determination mechanism and have transformer that don't depend
>>>on an action.
>>>
>>>
>>> <map:match pattern="*.xml">
>>> <map:action name="locale-select">
>>> <map:generate src="{1}.xml"/>
>>> <map:transform type="i18n">
>>> <map:parameter name="locale" value="{cocoon-locale}" />
>>> </map:transform>
>>> <map:transform src="simple.xsl"/>
>>> <map:serialize/>
>>> </map:action>
>>> </map:match>
>>>
>>>What about this?
>>>
>>I goes in the direction of what I want to avoid : multiple sources to
>>get the locale ;)
>>
>
>You can setup a matcher for all i18n requests and have single source -
>LocaleAction.
>
What do you mean by "i18n requests" ? Requests that use the i18n
transformer ? Then LocaleAction will be a top-level element in my
sitemaps :)
>>However, pluggable mechanism is possible with my second proposal :
>>adding Request.setLocale(). This method can be called by whatever
>>mechanism you want.
>>
>
>So, you'll need an action to call it - we are back to the LocaleAction ;)
>
Sure. But if LocaleAction changes the locale returned by
request.getLocale(), this value is then globally available, thus
avoiding the need for <map:parameter name="locale" .../>
>>>>>Are there any other wishes/suggestions/comments regarding i18n?
>>>>>
>>>>Yes : use the "cocoon-" prefix for the "locale" request parameters, as
>>>>for "cocoon-view" and "cocoon-action", to avoid potential naming conflicts,
>>>>
>>>'locale' parameters are configured in sitemap, so you can use any name
>>>for them (e.g.: 'locale-attribute" config param)
>>>
>>Ah, sorry, didn't notice that. But wouldn't it be better to default to
>>"cocoon-locale" ?
>>
>
>Have nothing against it. +0
>
I thinks there's a misunderstanding here : I was talking about the
_request_ parameter and not the _sitemap_ parameter returned by
LocaleAction. From what I can see, the _request_ parameter name is
hardcoded to "locale" in getLocale().
Also, I don't see a real need to configure the name of sitemap
parameters returned by LocaleAction since there is no possibility of
naming conflict, since the sitemap component is unambiguously defined by
the number of '../' in attribute values.
>So, maybe you'd start from LocaleAction (or Request interface) until I'll
>send my latest version of i18n transformer?
>
Please go on, as I don't have much time for this now.
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: i18n transformer update
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> Piroumian, Konstantin wrote :
>
> <snip/>
>
> >>I was thinking about how to merge these two different sources for
> >>locale. Having request.getLocale() and LocaleAction.getLocale()
> >>returning different results is IMO a bad thing since it can lead to
> >>inconsistencies between components that use one method or the other.
> >>
> >>We should have a single source for this information, and this is
> >>obviously the Request object.
> >>
> >>So I see two possible solutions, but there might be other :
> >>- having Request.getLocale() use the behaviour of
LocaleAction.getLocale()
> >>- adding Request.setLocale(Locale) to set the value returned by
> >>Request.getLocale(). This method would be called by LocaleAction.
> >>
> >>What do you think ?
> >>
> >Request object wraps HttpServletRequest and returns the locale that the
user
> >has selected in his browser, but that locale can be different from the
one
> >that the system supports. I don't know if any browser can set a new value
to
> >the http header that indicates the user locale. IMO, it's better to leave
> >Request object as it is now and have a helper class that will perform
custom
> >language selection.
> >
> That's really because environment.Request is an interface that what I
> propose is possible : determination of the locale can be interposed in
> the wrapper before actually calling HttpServletRequest.getLocale(). This
> has nothing to do with tweaking the browser's header or
> HttpServletRequest which BTW is not possible
But what if somebody will need the original user locale?
>
> >Maybe it'll be better to pass selected locale externaly it to the
> >transformer in the sitemap? This way we can use any locale
> >selection/determination mechanism and have transformer that don't depend
on
> >an action.
> >
> > <map:match pattern="*.xml">
> > <map:action name="locale-select">
> > <map:generate src="{1}.xml"/>
> > <map:transform type="i18n">
> > <map:parameter name="locale" value="{cocoon-locale}" />
> > </map:transform>
> > <map:transform src="simple.xsl"/>
> > <map:serialize/>
> > </map:action>
> > </map:match>
> >
> >What about this?
> >
> I goes in the direction of what I want to avoid : multiple sources to
> get the locale ;)
You can setup a matcher for all i18n requests and have single source -
LocaleAction.
>
> However, pluggable mechanism is possible with my second proposal :
> adding Request.setLocale(). This method can be called by whatever
> mechanism you want.
So, you'll need an action to call it - we are back to the LocaleAction ;)
>
> >>>Are there any other wishes/suggestions/comments regarding i18n?
> >>>
> >>Yes : use the "cocoon-" prefix for the "locale" request parameters, as
> >>for "cocoon-view" and "cocoon-action", to avoid potential naming
conflicts,
> >>
> >'locale' parameters are configured in sitemap, so you can use any name
for
> >them (e.g.: 'locale-attribute" config param)
> >
> Ah, sorry, didn't notice that. But wouldn't it be better to default to
> "cocoon-locale" ?
Have nothing against it. +0
So, maybe you'd start from LocaleAction (or Request interface) until I'll
send my latest version of i18n transformer?
>
> >>I also had a look at the key lookup stuff (including XMLResourceBundle),
> >>and it seems to me it is really performance-killing. Since I also need
> >>pluggable sources for translations, I will take this subject if you
> >>don't mind.
> >>
> >Sure. I'm not much expert in Avalon, lifecycles, etc. Note, that
> >XMLResourceBundle and XMLResourceBundleFactory are from Avalon scratchpad
> >and they can be out of date now.
> >
Konstantin
>
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: i18n transformer update
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Piroumian, Konstantin wrote :
<snip/>
>>I was thinking about how to merge these two different sources for
>>locale. Having request.getLocale() and LocaleAction.getLocale()
>>returning different results is IMO a bad thing since it can lead to
>>inconsistencies between components that use one method or the other.
>>
>>We should have a single source for this information, and this is
>>obviously the Request object.
>>
>>So I see two possible solutions, but there might be other :
>>- having Request.getLocale() use the behaviour of LocaleAction.getLocale()
>>- adding Request.setLocale(Locale) to set the value returned by
>>Request.getLocale(). This method would be called by LocaleAction.
>>
>>What do you think ?
>>
>Request object wraps HttpServletRequest and returns the locale that the user
>has selected in his browser, but that locale can be different from the one
>that the system supports. I don't know if any browser can set a new value to
>the http header that indicates the user locale. IMO, it's better to leave
>Request object as it is now and have a helper class that will perform custom
>language selection.
>
That's really because environment.Request is an interface that what I
propose is possible : determination of the locale can be interposed in
the wrapper before actually calling HttpServletRequest.getLocale(). This
has nothing to do with tweaking the browser's header or
HttpServletRequest which BTW is not possible
>Maybe it'll be better to pass selected locale externaly it to the
>transformer in the sitemap? This way we can use any locale
>selection/determination mechanism and have transformer that don't depend on
>an action.
>
> <map:match pattern="*.xml">
> <map:action name="locale-select">
> <map:generate src="{1}.xml"/>
> <map:transform type="i18n">
> <map:parameter name="locale" value="{cocoon-locale}" />
> </map:transform>
> <map:transform src="simple.xsl"/>
> <map:serialize/>
> </map:action>
> </map:match>
>
>What about this?
>
I goes in the direction of what I want to avoid : multiple sources to
get the locale ;)
However, pluggable mechanism is possible with my second proposal :
adding Request.setLocale(). This method can be called by whatever
mechanism you want.
>>>Are there any other wishes/suggestions/comments regarding i18n?
>>>
>>Yes : use the "cocoon-" prefix for the "locale" request parameters, as
>>for "cocoon-view" and "cocoon-action", to avoid potential naming conflicts,
>>
>'locale' parameters are configured in sitemap, so you can use any name for
>them (e.g.: 'locale-attribute" config param)
>
Ah, sorry, didn't notice that. But wouldn't it be better to default to
"cocoon-locale" ?
>>I also had a look at the key lookup stuff (including XMLResourceBundle),
>>and it seems to me it is really performance-killing. Since I also need
>>pluggable sources for translations, I will take this subject if you
>>don't mind.
>>
>Sure. I'm not much expert in Avalon, lifecycles, etc. Note, that
>XMLResourceBundle and XMLResourceBundleFactory are from Avalon scratchpad
>and they can be out of date now.
>
>Konstantin
>
>P.S. Btw, what is the coding standart for Cocoon sources? I use Sun's
>format, but somebody has reformatted several sources to something different
>and unusual.
>
The Sun format should be used. What sources are you talking about ?
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: i18n transformer update
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> Piroumian, Konstantin wrote:
>
> >Hi, C2ers!
> >
> >As I have a little free time, I'm going to make some code clean up in
i18n
> >transformer and LocaleAction. I've already added JavaDoc comments to all
> >public members and polished a little class comments.
> >
> Cool ! We're using i18n on our projects and I started digging in the
> code last Monday. I wanted to propose some changes (see below).
You're welcome ;)
>
> >Next I am going to create an I18nUtils class that will contain all
general
> >purpose i18n routines, such as locale string parsing, date/number
formatting
> >and parsing, etc. Currently, it will be placed in org.apache.cocoon.i18n
> >package.
> >
> +1.
>
> >Also, I'm going to add a new <i18n:get-locale> element that will use
> >LocaleAction.getLocale() to return the current selected Locale (it can be
> >different from request.getLocale()). (It'd be good also to move
getLocale()
> >to the new I18nUtils, but now getLocale() has a lot of dependencies from
> >Cocoon, but I want to keep I18nUtils as much general as possible).
> >
> I was thinking about how to merge these two different sources for
> locale. Having request.getLocale() and LocaleAction.getLocale()
> returning different results is IMO a bad thing since it can lead to
> inconsistencies between components that use one method or the other.
>
> We should have a single source for this information, and this is
> obviously the Request object.
>
> So I see two possible solutions, but there might be other :
> - having Request.getLocale() use the behaviour of LocaleAction.getLocale()
> - adding Request.setLocale(Locale) to set the value returned by
> Request.getLocale(). This method would be called by LocaleAction.
>
> What do you think ?
Request object wraps HttpServletRequest and returns the locale that the user
has selected in his browser, but that locale can be different from the one
that the system supports. I don't know if any browser can set a new value to
the http header that indicates the user locale. IMO, it's better to leave
Request object as it is now and have a helper class that will perform custom
language selection.
Maybe it'll be better to pass selected locale externaly it to the
transformer in the sitemap? This way we can use any locale
selection/determination mechanism and have transformer that don't depend on
an action.
<map:match pattern="*.xml">
<map:action name="locale-select">
<map:generate src="{1}.xml"/>
<map:transform type="i18n">
<map:parameter name="locale" value="{cocoon-locale}" />
</map:transform>
<map:transform src="simple.xsl"/>
<map:serialize/>
</map:action>
</map:match>
What about this?
>
> >Are there any other wishes/suggestions/comments regarding i18n?
> >
> Yes : use the "cocoon-" prefix for the "locale" request parameters, as
> for "cocoon-view" and "cocoon-action", to avoid potential naming
conflicts,
>
'locale' parameters are configured in sitemap, so you can use any name for
them (e.g.: 'locale-attribute" config param)
> I also had a look at the key lookup stuff (including XMLResourceBundle),
> and it seems to me it is really performance-killing. Since I also need
> pluggable sources for translations, I will take this subject if you
> don't mind.
Sure. I'm not much expert in Avalon, lifecycles, etc. Note, that
XMLResourceBundle and XMLResourceBundleFactory are from Avalon scratchpad
and they can be out of date now.
Konstantin
P.S. Btw, what is the coding standart for Cocoon sources? I use Sun's
format, but somebody has reformatted several sources to something different
and unusual.
>
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: i18n transformer update
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Piroumian, Konstantin wrote:
>Hi, C2ers!
>
>As I have a little free time, I'm going to make some code clean up in i18n
>transformer and LocaleAction. I've already added JavaDoc comments to all
>public members and polished a little class comments.
>
Cool ! We're using i18n on our projects and I started digging in the
code last Monday. I wanted to propose some changes (see below).
>Next I am going to create an I18nUtils class that will contain all general
>purpose i18n routines, such as locale string parsing, date/number formatting
>and parsing, etc. Currently, it will be placed in org.apache.cocoon.i18n
>package.
>
+1.
>Also, I'm going to add a new <i18n:get-locale> element that will use
>LocaleAction.getLocale() to return the current selected Locale (it can be
>different from request.getLocale()). (It'd be good also to move getLocale()
>to the new I18nUtils, but now getLocale() has a lot of dependencies from
>Cocoon, but I want to keep I18nUtils as much general as possible).
>
I was thinking about how to merge these two different sources for
locale. Having request.getLocale() and LocaleAction.getLocale()
returning different results is IMO a bad thing since it can lead to
inconsistencies between components that use one method or the other.
We should have a single source for this information, and this is
obviously the Request object.
So I see two possible solutions, but there might be other :
- having Request.getLocale() use the behaviour of LocaleAction.getLocale()
- adding Request.setLocale(Locale) to set the value returned by
Request.getLocale(). This method would be called by LocaleAction.
What do you think ?
>Are there any other wishes/suggestions/comments regarding i18n?
>
Yes : use the "cocoon-" prefix for the "locale" request parameters, as
for "cocoon-view" and "cocoon-action", to avoid potential naming conflicts,
I also had a look at the key lookup stuff (including XMLResourceBundle),
and it seems to me it is really performance-killing. Since I also need
pluggable sources for translations, I will take this subject if you
don't mind.
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: i18n transformer update
Posted by Vadim Gritsenko <va...@verizon.net>.
Konstantin,
It would be good if you could address two FIXME, one located in
XMLResourceBundleFactory.java, and another in I18nTransformer.java
Regards,
Vadim
> -----Original Message-----
> From: Piroumian, Konstantin [mailto:KPiroumian@flagship.ru]
> Sent: Thursday, January 24, 2002 4:26 AM
> To: Cocoon-Dev
> Subject: i18n transformer update
>
> Hi, C2ers!
>
> As I have a little free time, I'm going to make some code clean up in
i18n
> transformer and LocaleAction. I've already added JavaDoc comments to
all
> public members and polished a little class comments.
>
> Next I am going to create an I18nUtils class that will contain all
general
> purpose i18n routines, such as locale string parsing, date/number
formatting
> and parsing, etc. Currently, it will be placed in
org.apache.cocoon.i18n
> package.
>
> Also, I'm going to add a new <i18n:get-locale> element that will use
> LocaleAction.getLocale() to return the current selected Locale (it can
be
> different from request.getLocale()). (It'd be good also to move
getLocale()
> to the new I18nUtils, but now getLocale() has a lot of dependencies
from
> Cocoon, but I want to keep I18nUtils as much general as possible).
>
> Are there any other wishes/suggestions/comments regarding i18n?
>
> Best regards,
>
> Konstantin Piroumian
> Leading Software Developer
>
> Protek Flagship LLC
> Phone: + 7 095 795 0520 (add. 1288)
> Fax: + 7 095 795 0525
> E-mail: kpiroumian@flagship.ru
> http://www.protek.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org