[Xfce-i18n] Some requests

[Jasper Huijsmans]

Daichi Kawahata schreef:
> Hi developers,
> 
> I have some requests on i18n issues to keep a cooperative work
> between us (developers, translators) smoothly. You don't have to
> take these things immediately but after 4.4 released, I hope your
> considerations.
> 
>   1. PO file updates & bump on your side.
>   2. Using Q_() macro more frequently.
>   3. Using gray-out pane when some features are disabled.
> 
> 1. As you may already feel pain, now commits ML get flooded,
>    to reduce unnecessary logs at least, I sent a message to
>    xfce-i18n. Then, I'd like to ask you about updating/version
>    bumping PO files;
> 
>    a. When you bump the version up at configure.ac/in.in.
>    b. When you add the strings translatable to the source.
>    c. When you modify the source which contains a translatable
>       strings.
> 
>    One-stop updating across the entire modules I've been doing
>    makes toplevel ChangeLog ugly, hard to read, and obesity.
>    As for the version bump at the `Project-Id-Version', now
>    it's not that hard because they're already unified by me.
> 
>    The point of that is, they're also `your files' as well as
>    C source codes, and if that will be done by your hands,
>    commit log ML will be more regulated.
> 
>    Probably, the most annoying case would be `c' (only a bunch
>    of line number diffs), I'm still not sure how to update
>    them in a rule.

IMO, it depends a bit on the stage of development what is the best 
course of action. I agree that now, when we're in 'release mode' po 
files should be update immediately when anything changes.

However, when we're in 'development mode' with lots of changes it is 
often better to wait a while until thing have stabilized a little.

Now, back to bussiness...

Is it not enough to update the version just before a release?

> 
> 2. I've noticed that Q_() macro isn't only workaround for the
>    string separation but also aiding the translator for a better
>    translation, by the pointing out from Andras (new Hungarian
>    translator).
> 
>    If you put the single word used uncommonly, ambiguously,
>    please use a context label even when there's no string
>    conflicts. In my opinion, I don't think it's a tedious even
>    though I have to translate:
> 

If you add a comment just before the line containing the translations, 
it will be shown in the po file as well. That's a better way to give 
information to translators, I think.

   /* this comment will show up in the po file */
   do_something (_("text"));

> 
> 3. For example, a compositor doesn't work at all on IRIX, therefore
>    I can't see the strings should be appearing in the UI (Xfwm4),
>    if you put the feature not supported by all platforms, I'm grad to
>    see a gray-out (disabled) pane so that I can check the strings
>    translated at least.
> 

Hmm, I'm afraid that good UI design may be in conflict with the ease of 
translating in this case...

If at all possible it would be better to ask someone else who does have 
access to a system with these features to test your translations.

> Thanks for your considerations,

thanks,
	Jasper