[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Jay Treacy
that has been done, all future changes won't need any work

Reply to: