This is great news - thanks a lot.
I promise to make good use of that keeping the translation up to date.
Now that I've seen the ridiculously small patch you've done (congratulations - very good job!), I'd like to dive more into it and demand even more - this time I'll add an implementation right ahead:
I've frequently seen the situation where the english text was ambiguous (as the verb and subject was indistinguishable) and I had the feeling that the translation was bad, but couldn't tell for sure - and I'd like to use this flagging to signal other translators (or the remind me later).
Hooking into what you already did with ant filters, FilterChain can be utilized easily:
This will filter
where "feedback" can be thought of a signal to the implementors of the english version that the key is ambiguous in some language and requires some more context, and "note" is a hint to translators coming along later. They could even be combined, when the english translation gives a required context (from 'feedback') in a 'note' section in the english version (or a translator might provide the hint.
(Note: Somebody have a look at that regexp - it works in my test case, but I don't know all the pitfalls. It has garbled some UTF-8 test file, so filtering should be applied to the escaped file)
This might be a slight abuse of such a flagging system, but it'd be soooo convenient
I promise to make good use of that keeping the translation up to date.
Now that I've seen the ridiculously small patch you've done (congratulations - very good job!), I'd like to dive more into it and demand even more - this time I'll add an implementation right ahead:
I've frequently seen the situation where the english text was ambiguous (as the verb and subject was indistinguishable) and I had the feeling that the translation was bad, but couldn't tell for sure - and I'd like to use this flagging to signal other translators (or the remind me later).
Hooking into what you already did with ant filters, FilterChain can be utilized easily:
<copy file="in.properties" tofile="out.properties">
<filterchain>
<replaceregex pattern="\[note:.+\]" replace="" />
<replaceregex pattern="\[feedback:.+\]" replace="" />
</filterchain>
</copy>This will filter
center=Mitte [feedback: if this was a verb it'd be "zentrieren", this translation assumes that it's a noun]
consumer-agent=Verbraucher-Agent [note: need better translation]where "feedback" can be thought of a signal to the implementors of the english version that the key is ambiguous in some language and requires some more context, and "note" is a hint to translators coming along later. They could even be combined, when the english translation gives a required context (from 'feedback') in a 'note' section in the english version (or a translator might provide the hint.
(Note: Somebody have a look at that regexp - it works in my test case, but I don't know all the pitfalls. It has garbled some UTF-8 test file, so filtering should be applied to the escaped file)
This might be a slight abuse of such a flagging system, but it'd be soooo convenient
Ok, I've tested it, but found another issue. In my setup (just plain ant from commandline) everything was working well, without any jars placed anywhere.
The real issue I've found is that it's unclear which version of the Language_xx.properties[.native] is the leading one. The build process (in target build-lang-cmd) as I have seen it:
As LangBuilder re-generates the native file from the ascii file there's no chance to implement my suggestion without some more intense tweaking of this process. I'd fear to step on something I have not seen yet. I guess it's trivial for someone with insight to the build and translation process, unfortunately I currently can't dive deep into this. Even if I did I'd probably break something...
My expectations would be that the native file is the leading version, read by the build script. The ascii version IMHO could be generated during the build process and not be committed to svn. The native version would need to be touched by the automatic translation process for new keys, but other than that it should be manually updated.
Am I missing something?
BTW: In the process of trying this I've translated the marked german entries. Hunting for "(Automatic translation)" and "(Automatic copy)" works really well. Almost fun
The real issue I've found is that it's unclear which version of the Language_xx.properties[.native] is the leading one. The build process (in target build-lang-cmd) as I have seen it:
- first calls build-lang-native2ascii
- then invokes LangBuilder, which in _createProps() generates the native file again from the ascii version. During this process some translation magic happens
- then build-lang-native2ascii is invoked again.
As LangBuilder re-generates the native file from the ascii file there's no chance to implement my suggestion without some more intense tweaking of this process. I'd fear to step on something I have not seen yet. I guess it's trivial for someone with insight to the build and translation process, unfortunately I currently can't dive deep into this. Even if I did I'd probably break something...
My expectations would be that the native file is the leading version, read by the build script. The ascii version IMHO could be generated during the build process and not be committed to svn. The native version would need to be touched by the automatic translation process for new keys, but other than that it should be manually updated.
Am I missing something?
BTW: In the process of trying this I've translated the marked german entries. Hunting for "(Automatic translation)" and "(Automatic copy)" works really well. Almost fun