A simpler approach may be to merge the properties files at runtime, with property
values from more specific locales overriding those from the more general locales.
For example:
displaytag.properties:
export.decorated=true
error.msg.invalid_page=Where is it?
displaytag_es.properties:
error.msg.invalid_page=Donde esta?
Where "Where is it?" will the default value, unless the request is for an _es locale,
which will be served with "Donde esta?".
I'm concerned that a templating approach (with the #{} syntax) is yet another thing to
learn and keep in mind, while the override chain for properties seems like the
expected behavior for a java app.
I'm pretty familiar with the TableProperties and may be able to take a look at solving
this issue soon, although a lot will depend on Fabrizios 1.0 timeline.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Christoph Beck
> Sent: Tuesday, August 24, 2004 5:38 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [displaytag-devel] i18n
>
> It doesn't.
>
> You can find the modified TableProperties* files in the attachment.
> Please, see the README.txt file for comments.
>
> - Christoph
>
> ----- Original Message -----
> From: "Matt Raible" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, August 23, 2004 1:38 AM
> Subject: Re: [displaytag-devel] i18n
>
>
> As long as this doesn't break current functionality, I'm cool with
> adding it.
>
> Matt
>
> On Aug 22, 2004, at 4:36 PM, Christoph Beck wrote:
>
> > Hi,
> >
> > As far as I can see, displaytag doesn't support i18n by
> browser locale.
> > This is, however, an important feature in web applications we build.
> >
> > I went a bit into the code, to see what could be done with minimal
> > effort
> > and without breaking compatibility. Unfortionately, displaytag mixes
> > functional
> > properties, layout and localized strings in one properties file. To
> > avoid
> > copying everything for every language, local strings should to be
> > taken out
> > of that ensemble.
> >
> > This could be done by allowing property values to have embedded
> > resource
> > bundle keys.
> > Eg, a pattern of the form #{key} in the property value is
> replaced by
> > the
> > resource
> > value for 'key' at runtime.
> >
> > The modified TableTag.properties could then look like this:
> >
> >
> #-------------------------------------------------------------
> ---------
> > -----
> > ---------
> > basic.msg.empty_list=#{table.empty}
> > basic.msg.empty_list_row=<tr class="empty"><td
> > colspan="{0}">#{table.empty}</td></tr>
> >
> > basic.empty.showtable=false
> > basic.show.header=true
> > error.msg.invalid_page=#{invalid_page}
> >
> > sort.amount=page
> >
> > export.amount=list
> > export.decorated=true
> > export.banner=<div class="exportlinks">#{export.options}</div>
> > export.banner.sepchar= |
> >
> > export.csv=true
> > export.csv.label=<span class="export csv">#{export.csv} </span>
> > export.csv.include_header=false
> > export.csv.filename=
> >
> > export.excel=true
> > export.excel.label=<span class="export
> excel">#{export.excel} </span>
> > export.excel.include_header=true
> > export.excel.filename=
> >
> > export.xml=true
> > export.xml.label=<span class="export xml">#{export.xml} </span>
> > export.xml.filename=
> >
> > paging.banner.item_name=#{item_name}
> > paging.banner.items_name=#{items_name}
> >
> > paging.banner.no_items_found=<span
> > class="pagebanner">#{items.none}</span>
> > paging.banner.one_item_found=<span
> > class="pagebanner">#{items.one}</span>
> > paging.banner.all_items_found=<span
> > class="pagebanner">#{items.all}</span>
> > paging.banner.some_items_found=<span
> > class="pagebanner">#{items.some}</span>
> >
> > paging.banner.full=<span class="pagelinks">[<a
> > href="{1}">#{first}</a>/<a
> > href="{2}">#{prev}</a>] {0} [<a href="{3}">#{next}</a>/<a
> > href="{4}">#{last}</a>]</span>
> > paging.banner.first=<span
> class="pagelinks">[#{first}/#{prev}] {0} [<a
> > href="{3}">#{next}</a>/<a href="{4}">#{last}</a>]</span>
> > paging.banner.last=<span class="pagelinks">[<a
> > href="{1}">#{first}</a>/<a
> > href="{2}">#{prev}</a>] {0} [#{next}/#{last}]</span>
> > paging.banner.onepage=<span class="pagelinks">{0}</span>
> >
> > paging.banner.group_size=8
> >
> > paging.banner.page.selected=<strong>{0}</strong>
> > paging.banner.page.link=<a href="{1}" title="#{goto}">{0}</a>
> > paging.banner.page.separator=,
> > paging.banner.placement=top
> >
> > css.tr.even=even
> > css.tr.odd=odd
> > css.th.sorted=sorted
> > css.th.ascending=order1
> > css.th.descending=order2
> > css.table=
> > css.th.sortable=sortable
> >
> > # factory classes for extensions
> >
> factory.requestHelper=org.displaytag.util.DefaultRequestHelperFactory
> >
> > # resource bundle to lookup #{key} parts in properties
> > i18n.bundle=org.displaytag.properties.TableTagStrings
> > # default language
> > i18n.language=en
> >
> #-------------------------------------------------------------
> ---------
> > -----
> > ---------
> >
> > The last two properties are new.
> > * the 'i18n.bundle' property contains the bundle name to resolve the
> > #{key}
> > parts in
> > properties.
> > * the 'i18n.language' property contains a default locale to use.
> >
> > As usual, these can be overridden by users in their
> > displaytag.properties.
> >
> > An english version of the externalized strings
> > (TableTagStrings.properties)
> > might look
> > like this:
> >
> >
> #-------------------------------------------------------------
> ---------
> > -----
> > ---------
> > table.empty = Nothing found to display.
> > export.options = Export options: {0}
> > export.csv = CSV
> > export.excel = Excel
> > export.xml = XML
> > invalid_page = invalid page
> > item_name = item
> > items_name = items
> > items.none = No {0} found.
> > items.one = One {0} found.
> > items.all = {0} {1} found, displaying all {2}.
> > items.some = {0} {1} found, displaying {2} to {3}.
> > first = First
> > prev = Prev
> > next = Next
> > last = Last
> > goto = Go to page {0}
> >
> #-------------------------------------------------------------
> ---------
> > -----
> > ---------
> >
> > As an example, the german counterpart
> (TableTagStrings_de.properties)
> > reads
> > like this.
> >
> >
> #-------------------------------------------------------------
> ---------
> > -----
> > ---------
> > table.empty = Keine Daten vorhanden.
> > export.options = Exportiere nach: {0}
> > export.csv = CSV
> > export.excel = Excel
> > export.xml = XML
> > invalid_page = Seite ungültig
> > item_name = Eintrag
> > items_name = Einträge
> > items.none = Kein {0} gefunden.
> > items.one = Ein(e) {0} gefunden.
> > items.all = {0} {1} gefunden, zeige alle {2}.
> > items.some = {0} {1} gefunden, zeige {2} bis {3}.
> > first = Erster
> > prev = Zurück
> > next = Weiter
> > last = Letzter
> > goto = Gehe zu Seite {0}
> >
> #-------------------------------------------------------------
> ---------
> > -----
> > ---------
> >
> > So far, so good.
> >
> > Next, class org.displaytag.properties.TableProperties has to be
> > changed.
> > Basically,
> > * we construct instances by optionally passing in a locale.
> > * the bundle is loaded according to the specified locale.
> > * if no locale has been specified, we take the locale from the
> > 'i18n.language' property.
> > * if that isn't set either, we use Locale.getDefault().
> > * when serving property values, we replace the #{key} parts in our
> > properties.
> >
> > Now, if we do not always want to use a default locale, the table tag
> > has to
> > compute and pass the desired locale to the TableProperties
> constructor.
> > One way is to simply use request.getLocale() to take the locale
> > preferred by
> > the user.
> >
> > I have done things up to this point and it works fine.
> >
> > However, it is probably desired to explicitely state the
> locale (or at
> > least
> > language)
> > to be used. One possibility was to add an optional 'locale'
> attribute
> > to the
> > table tag
> > which would take a locale string like 'en_US', or one of the values:
> > * 'server' to take Locale.getDefault()
> > * 'request' to take request.getLocale()
> > * 'default' take locale constructed from 'i18n.language' property
> >
> > It is possible to implement these changes without breaking
> > compativility.
> > Displaytag
> > could come with a bunch of TableTagString_xy.properties files and
> > would then
> > really
> > support i18n.
> >
> > What do you think?
> >
> > - Christoph
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by Shop4tech.com-Lowest price on
> Blank Media
> > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> > _______________________________________________
> > displaytag-devel mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/displaytag-devel
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> displaytag-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/displaytag-devel
>
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
displaytag-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/displaytag-devel
