Last modified: 2011-08-18 16:43:44 UTC
When European Portuguese messages don't exist, the Brazilian Portuguese version should be used as a fallback before going to the default (English). The language fallback code features loop detection code, so the fact that the opposite fallback pair exists (pt-br fallbacks to pt) shouldn't be a problem. So, apart from the pt-br --> pt fallback, a pt --> pt-br link should also be added. A specific issue that would be solved by this change is the behavior of the {{#language:}} parser function, of the CLDR extension. Due to (1) pt-br being the default in CLDR (which is where the #language parser function gets its data) while pt-pt is the fallback, and (2) the way CLDR stores values in their database (for each variant, they only store the values that are different than the default variant), the European Portuguese language names aren't listed for most languages, and fallback to the English name. For example, {{#language:pt|pt-br}} returns "português" (correct), but {{#language:pt|pt}} returns "Portuguese" (wrong). Having this fallback in place would make the system work correctly.
Tagging this with needs-unittest -- this is exactly the sort of subtle thing that could break in several ways (breakage of loop detection code, refactoring accidentally dropping one of the connections, or changes to CLDR), so the patch for it should definitely include test cases.
this is a test. ignore this.
Thinking about this more, there are probably many places which just loop through the fallbacks - and I think we should not break that assumption. How about providing a function that returns a full fallback list for a given language, like: pt -> pt-br, foo, ..., en pt-br -> pt, foo, ..., en For this we would need to introduce a new variable in the message files, or extend the current one with a new syntax.
Any further discussion needed before we can proceed as proposed in comment 3?
r94908.
