2011.12.28 21:09, Adrien Destugues rašė:
> de_DE is actually de, so de_CH will fall back to de automatically. > >> [Other examples for this would be en_US and en_GB.] > > en_US is actually en, so en_GB will fall back to en automatically. > :) This will work at runtime, but you can't see it in Pootle (nor HTA). So you have to take a look at the other language to see what needs to be changed.
You're wrong about HTA. It does visual inheritance, here's the screenshot: http://bugs.locamotion.org/attachment.cgi?id=662 .
In Pootle, this is not implemented, but if e.g. the localizer into de-CH will choose de as an "alternative source language", (s)he will be able to see what that string is in de and leave it untranslated if there's no change needed. The bad thing about this is that Pootle will see that string as untranslated, and it will hurt both the statistics and the usability in general (such as finding newly introduced strings). I've filed a feature request for Pootle to implement this quite a long time ago, but that bug hasn't moved anywhere yet. http://bugs.locamotion.org/show_bug.cgi?id=1526 .
By the way, one of the Pootle developers expressed an opinion about this feature that is worth considering:
I think he might be right. Inheritance is a good feature, but asking the localizer of ll-CC not to copy-paste a good translation from ll is risky at least. What if ll changes their localization after ll-CC chooses to inherit it? What if the new version doesn't really suit ll-CC anymore?I find this a strange feature: you leave something empty and rely on another translator not doing something you don't like.
Perhaps we should actually discourage explicit inheritance like this, and instead suggest the localizers to use copy strings when applicable? (Nothing would have to change in the code, inheritance would still work, but it would simply not be encouraged).
Rimas
