Hi Frank,
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Ivo,
- The German entries in resource files ( *.src / *_tmpl.hrc ) have been
converted to UTF8, thus there is no more different handling of German
and English US entries like before ( MS1252 vs. UTF8 ). You may get
conflicts during cws resync caused by this change. In this case convert
your new / changed strings to UTF8.
Dumb question: how do I do this? I darkly remember that a while ago, we
discussed whether all our editors in engineering are capable of encoding
in UTF-8 automatically (if some signature byte at the beginning of the
file requires this), but not sure what was the outcome.
Take care that _your_ favourite editor writes UTF8, I don't know what
"all our editors in engineering" are.
In other words:
If, in the future, I want to enter arbitrary germany text containing an,
say, ü, into an arbitrary .src file - what do I need to care for?
Open that file for example in firefox, set View->Character
Encoding->Unicode (UTF8) and if you still see "ü" -> ok , if you see "?"
, "[EMAIL PROTECTED]" , or similar -> something is wrong
- There is a new flag file <module>/prj/l10n which indicates the
existence of German localisation. If this file exits, all resource files
( *.src / *_tmpl.hrc / *.xcu / *.xrm / *.xrb / *.ulf ) in the whole
module source tree contains both languges, German and English US. If
that file lacks, only English US is present and the German translations
are located, like all other translations, in the localize.sdf files in
each directory. If you introduce a new module please add such a file
into your <module>/prj/ directory if nessesary!
I suppose this requirement will be documented somewhere? Just kidding ...
yes, in #i49922# ;)
Any objections to treat German as a usual translation language and
remove the German entries complete from all resource files in the future?
Today, the process for new strings involves specifying both the germany
and the english string in the spec document, and writing them into the
.src (done by the developer). If the german string is not to be entered
at source-level anymore, how would this work? Would only the english
string be specified, and the german version is part of the usual
translation process?
Yes why not! To handle German as a usual translation language has a lot
of benefits:
- In a international open source project having German source language
strings looks a bit strange to me ( and confuse non German speaking
developers a lot )
- There is only one "truth" . Imagine you have two strings where en-US
and de translation does not match. What is the "real" one ? We already
had such cases.
- Consistency, there is no mix with resources having en-US only or en-US
+ de string ( #i49922# )
Thanks & Ciao
Frank
Cheers,
Ivo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
