It's exactly then that the issue I'm talking about is the most visible. I'm language manager for Swedish. We stay close to 100% translation a lot of the time, but the strings are a moving target. HTA never stays 100% green for very long, due to changes in the code. Also the translators work all the time, try strings, try names, discuss, change strings. This work essentially -removes- strings until the manager approves them. This work is on-going. Completion does not mean things slow down or go silent. If I commit a set of catkeys where the state is less than 100% whereas the set in SVN were 100%, that is a step back. And that's something I think a proper workflow can avoid. The language should sign off on a definite set of catkeys, in the form of a tarball, since that's the only means of snapshotting HTA currently.
You're right, but we're still in a transitional period :* The internationalisation of the code itself is a problem, we change things to make them more easily localizable * There are changes from the translators because the guidelines are not set in stone. Note you can easily test your changes without having them commited on svn, just drop the catlkey files in an haiku image.
* there are a lot of new languages altogetherSo it's really noisy right now, but Ithink after some time, it will slowdown quite a bit.
I'm not saying the process should be made less noisy, for example building the catalogs offline in hta, creating an optional package for each language and downloading them when building an haiku image is a viable solution that avoids a lot of commits. But this eeds package manager first :) It's a needed step anyway, as you may want to update localization of a program without changing the code...