[WG: I18N & L10N] Merging issues with i18n components question

Matthew Jones matthew at longsight.com
Thu Apr 12 08:26:08 PDT 2012

I saw that Earle marked
SAK-19830<https://jira.sakaiproject.org/browse/SAK-19830> as
merge. This is a good patch as it clarifies the message from something
ambiguous to something clear, however the problem with it is it adds a new
language property that didn't exist before.

I believe that Jean-Francois had said not to merge this and others like it
because string freeze was a long time ago.


So would this be a candidate for 2.9.1, or would this never be a candidate
for 2.9? Could this patch be considered if it had backward compatibility
built into it, so instead of:

 addAlert(state, rb.getString("theemaali4"));

It was

 addAlert(state, rb.getString("theemaali4",rb.getString("theemaali2"));

In this second case, it would check if the new value exists, if not it
would return the old string value, ensuring that a translated property

Or maybe even better, if a method existed in ResourceLoader
//First parameter is the optimal, others are less optimal but acceptable
public String getString(String... args) {


So then we could just call rb.getString("theemaali4","theemaali2");
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/i18n/attachments/20120412/b6d9d2a6/attachment.html 

More information about the i18n mailing list