Gregor Hartmann wrote:
How to automatically localize qatesttool environment
...
The problems would be
a) how to generate a unique identifier for each string which *never*
changes (well at least almost never)
...
For a) there are several solutions.
I) there are so called KeyID Builds provided by SUN, but of course
only for some languages. In these builds each string is preceded by
its ID From the database, which is unique and does not change. The
problem is that these IDs are not available to the Community (yet).
There are KeyID Builds by the community, namely Pavel, but their
numbers change from build to build and thus are not suitable in this
case.
Is seems however that there are some free fields in the sdf files
which could be used to store these SUN KeyIDs in. This would be done
in the normal l10n CWSes.
The problem wold be that the ID would be available for new strings
only after they have been translated, but OTOH a localized Office is
not available before that either.
I would love to see the KeyID connected to a string in every OOo build.
This would also make it easier to find a string in the database - even
if the database is not public and even if it is not a KeyID build.
The id could be made visible with the declare.bas tool ? - Instead of
the current variant by printing the KeyID next to the string in the UI.
...
The file(s) containing the translations could be generated by a script
which has two input sources. First A file containing the needed IDs,
second an sdf file containing all translations of the office. It would
then write a file for each language found in the sdf file containing
lines with the fields ID and Translation.
What do you think about this, is it a good way to go? There is some
work to do but in the end localizing a new language is done in no time.
cheers,
Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
