Re: Problems with localized Pages
On Sat, Feb 13, 1999 at 10:37:45AM -0500, Michael Stone wrote:
>
> I'm a little leery of this. I'm not sure that we want automatic
> translations of things that could be serious issues. Sometimes the
> instructions can get fairly complicated and I wouldn't want to run to
> risk of bablefish-ing them. (E.g., "disable such-and-such if this other
> thing is true, otherwise you'll be ok but you should try to get the new
> version as soon as it comes out to avoid future problems.")
>
The issue we are trying to address is synchronization problems with the security
pages. It is precisely because these pages are important that this was proposed.
Only standard items are translated automatically. For example, 'Date Reported',
'Affected Packages', etc. As stated near the end, it is NOT the responsibility
of the maintainers of the security pages to translate any other text on the
page. Nothing like bablefish should ever be used on something like this.
Furthermore, the quality of translations is never the responsibility of the
security team.
In the hopes of clarifying why I set everything the way I did, I'll list a
number of situations and how they are handled.
1. Initial posting of a security alert - no translations
In this case only an english version of a security alert exists so
no synchronization problems can exist. There are some issues which need to
be worked out on how the index pages will grab the correct version of
text (translations when available, but the english version otherwise)
but that shouldn't be of concern to the security team - the webmasters
will take care of it.
2. Translation of a security alert
If, as is currently done, translators make a translated copy of security
items in their language directory then synchronization can become a big
problem. To avoid this, it was proposed that everything be kept in the
original security alert so that any future changes will be seen by the
translation - even if that means that portions of the page aren't translated.
How then are pages that have been translated generate the .<lang>.html file?
The translator simply creates a file in their language directory with the
same name as the english file and a single line in it that #includes the
english version of the file. Only if one of those files exists will a
security alert be created for that language. Wml selects the slices
corresponding to the current language when generating the .<lang>.html file.
3. Updates to a security alert with existing translations.
If the english page is updated after a translation has been made, then unless
done properly, any existing translations won't see the changes. New text
must use slices so that translations can be added. The problem is then that
existing translations won't see the new text, since a slice doesn't exist in
their language. That is why new text must be copied into slices for every
existing translation. Until the translators update the file, every .<lang>.html
file will see the new text in english. This better than the alternatives.
There is still one problem. What should the security team do if they need to
modify existing text (as opposed to adding new text) that has been translated?
I propose that we create a tag <outofdate> that is added to the first of each
translated slice. This tag will print a message stating something like 'This
translation is out of date. Please refer to the English page for the most
recent information'. Translators can remove the tag when they update the page.
For most security alerts, only the description will need human translation, e.g.
security/1999/19990104. Once that is done, the 'Fixed in' information can be added
and will be handled automatically. In other cases, e.g. security/1999/19990210
a number of updates to text needing human translation will be needed. Even in
that case, though, the amount of text is small and the proposal above should
suffice.
Jay Treacy
that has been done, all future changes won't need any work
Reply to: