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

[Christian Rose <menthos gnome org>]

Hi!
Lots of interesting stuff, too bad we didn't have more time at GUADEC to
discuss these issues.


tor 2003-06-26 klockan 13.24 skrev Breda McColgan:
> What do you think? Would developers prefer to have multiple problems
> logged in a single bug, or one bug per problem?

In general, from my experience, many developers seem to prefer seperate
bug reports, one for each seperate issue, as long as the issues found
aren't almost identical and don't belong to the very same part of the
application or even the same source files.

There are many compelling QA reasons for this atomic, specific
reporting; reasons that I totally agree with:
1) Different issues may need different solutions
2) Different issues may be solved at different points in time
3) Issues in different parts of a big application may be fixed by
different developers, and such issues may need assignment to different
developers

As po files in general cover all or many different pieces of a module,
possibly parts from hundred of vastly different source files in a large
module, I think reporting huge "all-in-one" reports should in general be
avoided, unless it's absolutely clear that all the issues covered in the
report are almost identical and cover almost the same source files.

Huge all-in-one reports tend to be difficult to read and track to begin
with, and with time and comments added and the different aspects of the
points 1), 2), and 3) above, they usually only explode in unreadability
from there on, in my experience. All the different solutions need to be
explained and possibly discussed and evaluated in the same report, and
it's difficult to close a bug report as "resolved" when it covers many
different problems that have different complexity and that may be solved
at different points in time. Such a report could perhaps stay open for
long times just because only 9 out of 10 issues mentioned in it have
been solved yet, and as a big aspect of QA is being able to easily find
out what issues have been resolved and what haven't, this can easily
turn out to be a needle in a haystack problem, i.e. you have to wade
through lots of already resolved issues in a single report just to find
the one which isn't.

So, in general, I would recommend seperate bug reports. The drawback is
of course that extra time and effort spent in reporting, but I think it
is well spent time if it can actually bring bug reports to usefulness
instead of being an untrackable mess in many cases, since that goes
against the whole point of bug tracking.

I guess we need to bring this up in possible recommendations for bug
reporting for translators, in case we should have such. Perhaps
recommendations like this:

        * Are the issues you intend to report identical or almost
        identical (same formatting of messages issue, etc)?
        * Do they come from the same or almost the same source files
        (look at the source file reference lines)?
        Unless you can answer yes to both of these questions, please
        report the issues as seperate bug reports in Bugzilla.


> 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.
>   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.
>
> What do you think of this proposal? 

Excellent, I'll try to add a note about that in
http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html.


> TOPIC THREE
> ===========
> Another discussion featured the problem of how to translate non-ASCII
> characters. One example given was the copyright symbol. I didn't realise
> at the time that the BOF was developer-focussed only, or I would have
> suggested that the translators could consult their writer colleagues to
> see how this is done for documentation translations. But perhaps I am
> misunderstanding the problem?  As coincidence would have it, Sasha sent
> a mail last week that included an excerpt from a mail that he originally
> sent in February 2002 -- perhaps this could help to solve the problem?
[...]
> > File syntax is obvious. Just note that non-ascii characters must be
> > encoded as unicode character entities, e.g. Ͽ 

This problem seems to be different. Non-ASCII characters are of course
allowed in translations in po files, the problem is that they aren't in
general allowed in the original messages due to technical issues with
gettext. Encoding them with escape references doesn't help, as they
still are treated as their proper character value by gettext. This
problem needs solving at the tool level, and it looks like there has to
be changes made to intltool and that we need to depend on newer versions
of both intltool and GNU gettext.


Cheers,
Christian