Martin Srebotnjak wrote:
A simple comparison of changed strings (and there are up to 2000 changed strings, like in m57) in sdf file would show the QA representative what is going on in the milestone; it would take 10 minutes to browse through the comparison file to see what kind of changes appear and if they look suspicious;
So what would happen then? A help release would be further delayed. We need to make sure that insignificant unintentional changes don't make it to the help in the first place. And intentional changes like emph > item would not look suspicious just because they are numerous.
Should there be a limit put on how many strings can get changed by a single "normal" CWS or milestone? Like 500 strings? This would force documentation writers not to wait to the last milestone before the
You are implying that help writers are "waiting to the last milestone" because they like to, and "forcing" them to do it differently would somehow change the situation. Help writers depend on engineering finalizing the features. We are not doing this to annoy localizers. This is not an approach that will work, trust me. Docs and localization are at the end of the food chain and we'll stay there. If the deadlines for localization are too short then work with the release managers to get more time for localization. The root cause here is that we are releasing all language versions at the same time and trying to squeeze localization into too short timeframes. You are blaming documentation but you are actually barking up the wrong tree.
string freeze with almost all changes, and would be more translators friendly. The period of translation checking after string freeze is eroded also by translating instead of mostly testing, at least in the first week of so, because so many strings always changed in the last milestone just before string freeze.
And changes to help could get checked throughout the development cycle by non-English users in native languages as well (like from Pavel's builds), if translators can work more gradually.
I agree, this approach is highly recommended, yet proved to be completely unrealistic, unfortunately. 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]
