Quote:
Originally Posted by ixtab
@eureka: I had been thinking about a less "brutal" way for semi-translated resources. Forcing 100% completion is technically ok, but it's not ideal, because people will probably tend to copy over the english strings, instead of leaving them untranslated. This makes it harder to find strings which actually are, in fact, still untranslated inside a "100% translated" resource.
For gettext, this is not a big issue, as there are only few strings. For Java, the problem is that untranslated keys get assigned an empty string as the value. However, since I'm parsing the resources anyway, I could simply throw away such key/value pairs. This would have the advantage that one can also test-drive semi-translated languages. Should I implement this?
|
It would be good. Thanks for the idea!
(I'll try to implement it for the JS part. JS resources doesn't inherit as Java bundles and all resources must have a value, but there is a workaround: on converting from .properties to .js I can take localized resources from, say, *_ru_RU.properties and merge them with original resources from *_en_US.properties with priority of localized resources.)