View Single Post
Old 01-20-2012, 06:53 AM   #124
eureka
but forgot what it's like
eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.
 
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
Quote:
Originally Posted by ixtab View Post
@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.)
eureka is offline   Reply With Quote