On Fri, 2007-04-06 at 02:58 +0100, Dimitris Glezos wrote:
O/H Paul W. Frields έγραψε:
So it sounds like we will have annoyances no matter which choice we make:
- Using "xml2po -k" and keeping entities intact like &NAME; there are
translators who will be inconvenienced. They can still substitute translations for the entity -- using the right form of "SomeName," instead of the exact string "&NAME;" -- but there will be no benefit to them in the event the entity changes. They may not even notice that it *has* changed unless they are watching the docs-common/common/entities/po/entities.pot file, and making the mental connection.
- Using "xml2po -e" and transforming the entities into strings in the
POT file, so "&NAME;" becomes "SomeName," it will be painful to change single strings in a minor way, since *many* fuzzy entries potentially result from trivial changes.
So, we (translators) need to decide here:
- Following 1., some translators behave differently than the others and
hard-translate the entities (substitute "&NAME;" with "Somename") when they need to. When an entity changes ("&FOO;" becomes "Fedora 8") the translator will have to manually update all occurrences for this language of "Fedora 8" to "Fedora 9".
- All languages will get fuzzy translations once an entity changes. All of
them will have to do the job described in 1.
So, the Q is: How often does an entity change and how big is this change? At this period we are changing "Fedora Core" -> "Fedora" and "Fedora Core 6" -> "Fedora 7". Later we'll probably only do the latter every 6 months.
Some entities change less often, others more often. In the future I expect us to have a more robust test cycle for documentation, and you'll be looking at monthly changes for things like "test2" => "test3". A small change, but it would echo throughout many, many documents and message strings.
If we choose 1, we can make sure that we notify those language teams that substitute the entities that the entities have changed. They can then search-and-replace all their files and substitute everything at the same time (with a tool like `regexxer`). So 1. might not be as bad as it sounds after all.
-1 "we notify"; scaling problem +1 subscriptions to fedora-docs-commits@redhat.com