Martin Srebotnjak wrote:
2009/9/18 Ain Vagula <[email protected]>:
hcshared22 also introduced a lot of needed changes about new or
changed features in 3.1, so we cannot use older source here.
This is something I proposed here but my idea was not accepted well.
I proposed that help changes would come in smaller packages that would
be easier to control. Now I can give this idea an even clearer form.
The help CWS' could be divided to two or more sorts - new strings
adding new functionality descriptions, automatic source changes (like
tags and icons, done automatically on localization teams SDF's) and
editing of English strings.
Your approach is correct and I absolutely second that. In fact,
what Uwe tried to do is
1. New functionality
New features should only be documented inside the feature CWS.
Unfortunately, this doesn't work in all cases since not all
developers follow this procedure. Therefore, Uwe is forced to
change those inside the hcshared CWSs.
2. Automatic source changes
What you are probvably referring to here are the bulk
changes that are insignificant for l10n but still occur inside
elements to be localized.
Normally, those do not happen consciously. As we found out during
these discussions, many of these came in by error (formatting
XML editors etc). We need to make sure before comitting source
changes that they are normalized and therefore do not have these
bulk changes.
For other changes, like the emph>item change, I agree to implement
a process that allows us to automate the change in source and SDF.
That would involve a "quiet period" where no localizations are
pending to be imported to make sure that those do not override
any changes made directly to SDF.
3. English string edits
This is the real purpose of hcshared, new features ony occur there
because we failed to make them in the feature CWS. In future, we need
to make that a more strict policy, so it seems.
Namely, I have seen that also changes in English strings are a bit
frustrating for us non-English localizers - in English strings
sometimes just fixing a typo makes the string in your language fuzzy,
but actually your translation should be just fine. But you want to
make it sure what changed and if translation is ok etc. and you lose
precious time. If one knew that a typo and English content changing
CWS is coming one would go translating through it in a different way
compared to an new strings CWS.
That is hard to catch without having a flag that says "I changed
something, but it's irrelevant to l10n".
But I guess having several CWS' in this way would make a hell to
documentation writers who would have to split changes to two different
CWS even in the same string and that would really be stupid.
Yeah, that would be impossible to handle. CWS maintenance is quite
a bit overhead.
However, could English language (en-US) become just one of
translation/localization languages? That way when typos would be
changed the main SDF would not get changed, just the en-US translation
of the SDF? The localizers would get the changes to translate only
when there would be new strings and when editing of existing strings
would change or clear their meaning.
I guess, Ivo and the guys from Releng would need to answer this one.
Frank
--
Frank Peters
The OOo Documentation Project:
SIGN UP - PARTICIPATE - CONTRIBUTE
IT'S FREE! NO OBLIGATIONS!
http://documentation.openoffice.org
http://wiki.services.openoffice.org/wiki/Documentation
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
