[WG: I18N & L10N] [cle-release-team] Merging issues with i18n components question

Aaron Zeckoski azeckoski at unicon.net
Thu Apr 12 08:32:57 PDT 2012

I would vote for merging this into 2.9 now. Surely the 2.9
translations have not already been done right?

On Thu, Apr 12, 2012 at 11:26 AM, Matthew Jones <matthew at longsight.com> wrote:
> I saw that Earle marked 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.
> https://confluence.sakaiproject.org/display/REL/Sakai+2.9.0+Release+Schedule
> 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 exists.
> 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");
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team

Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile

More information about the i18n mailing list