from the maven perspective package level localisation at the package (groupId)
level is the easiest implementation
introducing class-level filters implies the need for a class level filter
(instead of applying localisation at the package level)
same goes with <Application>.properties where the build utility would choose
priority of language based on some external criteria
(packageLevelLocalisation/classLevelLocalisation/versionLocalisation)
there is a growing need for build engineers to build one package for english,
one package for german and one package for french
during RC (release-candidate) promotions
http://maven.apache.org/plugins/maven-site-plugin/i18n.html
maybe wes or paul benedict can offer some advice on their experience
Martin
---------------------------------------------------------------------------------
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und
Vertraulichkeitanmerkung/Note de déni et de confidentialité
Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése
nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi
alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen
megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet
tartalma miatt.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> Date: Fri, 24 Sep 2010 11:17:06 -0400
> Subject: Re: S2 overriding a Localization property
> From: greg.lindh...@gmail.com
> To: user@struts.apache.org
>
> Yes, a more explicit override mechanism would be a good idea as the
> Bundle Search Order mechanism seems to have some weaknesses. (This is
> all assuming I'm understanding it correctly.)
>
> How would I override properties that are in an class-level properties
> file since this seems to be the most specific location? The only way
> I can imagine would be to provide my own version of of class-level
> properties with the same name and ensure it is earlier on the
> Classpath. In this case it seems I would have to provide a "full
> replacement" with all properties not just the properties I'm
> interested in overriding (if it finds my class-level properties file
> will it look for others with the same name or just move up the
> chain?).
>
> Here is different situation that also seems weak; if i want to
> override a property that is in a package-level properties file I could
> provide a class-level properties file but if the properties are used
> by more then one action class I would need to provide multiple
> class-level properties files, one for each class that uses the
> property.
>
> I think a better mechanism would be a facility to configure a "look
> here first" properties file and if not found then continue up the
> Bundle Search Order. Essentially allow the developer to insert a
> bundle into the front of the search order.
>
>
>
> On Thu, Sep 23, 2010 at 5:05 PM, Dave Newton <davelnew...@gmail.com> wrote:
> > Provide a more-specific location--so as long as they can create a package-
> > or class-level properties file that's more specific there's no issue. Are
> > you looking for a different mechanism than that?
> >
> > Dave
> >
> > On Thu, Sep 23, 2010 at 5:02 PM, Greg Lindholm
> > <greg.lindh...@gmail.com>wrote:
> >
> >> How do you override a Localization property that is bundled in a
> >> ActionClass.properties file?
> >>
> >> I'm planing on bundling up some common Action classes into a jar to be
> >> used by several projects. I plan on putting their properties in
> >> ActionClass.properties files that get bundled into the jar.
> >>
> >> I would like the individual projects to be able to override the
> >> supplied properties if they need to. I'm looking at the "Resource
> >> Bundle Search Order" and it appears that it will in the
> >> ActionClass.properties file and if it finds the property it will stop
> >> looking any further. So how do you override?
> >>
> >> Thanks
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> >> For additional commands, e-mail: user-h...@struts.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
>
