En vie, 2001-11-16 a 23:13, Ignacio J. Ortega escribi�: > > > > I have updated the new user confirmation email to use a > > template for the > > message. This will allow a language specific "message" to be > > sent. To > > complete the task, I need to send a language specific "subject". > > > > Some ways to do this: > > 1) On way is to use entries in JR.p. > > Disadvantage: Adds a lot of entries to JR.p > > > > 2) Use Velocity template for subject. I am already doing this for > > the message body. > > > > 3) Use Localization.getString(). > > Where are the language specific values stored? > > > > I think the solution is a mix between 2 and 3, use a template but > localized with Turbine l10n service, this way you get best of both > worlds a completely costumizable subject with a localized message easily > configurable..-- >
If I remember right, the issue was discussed previously. The point of view of Raphael was that having everything in localised strings would not work in a templating environment, because (for instance) right-to-left languages like hebrew or arabic, would call for completely different layouts and templates. Nevertheless, there is an issue with regards to login messages (like "Login Failed: no such user" or "Wrong password". These strings correspond to system messages and they should be in localised strings. (I don't really object, I just support your point). I think the toolbox allows us to have a solution like the one you are suggesting. The only remaining issue would be to mark those "message" strings and localise them, as oposed to templates. > *.properties files is the way to go.., JetspeedLocalization*.java seems > not used right now.. and it's a very bad format.. almost evry ide has a > properties edtiro.. so.. > Yes, but only for messages. Templates are much cleaner for things like login portlets, emails,... We just deliver a set of standard templates, and we can have translation teams delivering Spanish, French, Chinese, ... subtrees + one properties file. This was one of the reasons why I have always pushed unicode for us. We want a truly global server. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
