> > Umm interesting, I can see your point that maintaining lots of files > is a pain - but its just feels(?) nicer to put the whole text into > the template - rather than 3 or 4 localization strings around dynamic > bits.... >
Having the experience of maintaining this kind of system, i know the problem closely, and finally the good solution is somewhat more radical, strings finally go into db.. (or xml for that matter) ( next is a Ramdom thougth take it with care :) The problem for the maintenance is that is cumbersome to maintain the "default" language.., this is easy solved by simply adding a default parameter inside the Localization call, and do not using *.properties files for that language, something like : $i10n.getString(SENDCONFIRMATIONEMAIL_SENT, "Email Sent!"} or in java code Localization.getString(SENDCONFIRMATIONEMAIL_SENT, "Email Sent!"} This way maintaining the default language is easy ( well more verbose but only editing the template will be needed ), in addition we can invent new keys as needed, later when using the pages, spit some information in logs about missing keys, this will make easy to add them to the correspondent *.properties file.. What do you think ? > And having one big file (per language) full of localization strings - > that maybe unused now... - seems a bit cumbersome too... > This is correct, finding unused strings is difficult.., and having a big file for that too, but for someone doing the REAL job, is far more easy than to have to modify and format a bunch of files.. think of it i will be doing next, and i think that the price you pay with the above solution is really easy to maintain "en", makes life easier for all other poor not "en" guys :)) > Maybe its just a bit more disciplined than I have been to date... ;-) > > But I will follow the crowd. > > Chris > Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
