Re: Promoting greater integration between developers/writers/I18N :)

[Mark McLoughlin <mark skynet ie>]

Hi Breda,

On Thu, 2003-06-26 at 12:24, Breda McColgan wrote:

> TOPIC ONE
> =========
> A lively discussion arose about the best way to handle errors found in
> the po files by translators. 

	We're talking about typos, wrong terminology and i18n issues, right ?

[snip]


> What do you think? Would developers prefer to have multiple problems
> logged in a single bug, or one bug per problem?

	Trivial problems should be logged altogether in a single bug, harder
problems should have individual bugs.

	One problem I have as a maintainer is who should I take as having the
final word on such things e.g. if some piece of terminology is changed
in a UI review, a translator suggests that some other terminology is
better and then a writer comes along with a different suggestion. In
that case, I don't want to have decide myself - I'd like to be able to
cc a single person or alias and say "You guys decide". Who should I cc ?

> TOPIC TWO
> =========
> Of course, ideally we should try to minimize the number of errors in the
> first place :)
> 
> Among other topics, Christian outlined the problems that translators
> face when translating system messages. I suggested that the developers
> should:
>   o Read the "Writing for Localization" chapter of the GDSG, to avoid
>      common I18N pitfalls when writing the system messages.

	Sure, this makes sense - just like it makes sense for every developer
to read the HIG. However, its quite likely that a lot of hackers either
won't read the GDSG/HIG in full, won't understand it fully or will just
forget what they read.

	The HIG guys are thinking of doing a quick checklist type thing for
developers. It would perhaps be better if we had a combined checklist
thing for issues relating to usability, a11y, i18n and documentation
with pointers into each of the individual guides for more information.

>   o Ask their friendly documentation buddy to review the system
>      messages, because:
>      - Writers can point out text that is difficult to translate. 
>      - Writers can also advise when error messages are too long or too
>         short, and provide alternative suggestions.

	I'm not exactly sure of what you mean by "system messages". Do you mean
messages in error/warning dialogs or messages printed to the console. If
its the latter I'm not sure we even consistently mark them for
translation :/

	I'm also not sure how to work it so that hackers would get messages
reviewed ... I don't think developers typically put, or even want to
put, too much thought into the error/warning messages they are writing.
Its usually a diversion from the task at hand e.g. if you are hacking on
some feature, you don't want to spend much time on error conditions ...
I'm not saying that is ideal, I'm just being realistic about it :-)


Good Luck,
Mark.