Re: String addition to gnome-terminal

[danilo gnome org (Danilo Åegan)]

Hi Josep,

(stripping most CCs)

Today at 18:46, Josep Puigdemont wrote:

>> Having 100% translation is useful for more things than
>> show-off:
>>  - it's easier to notice new strings/string changes!
>> (this is important for the same reasons we have a string freeze at all)
>
> I'm not following here. It's actually when the translation is not 100%
> done that one  realizes that there are new strings to translate.

Exactly.  And if we introduce new string which might end-up
untranslated, I'd either have to translate it, or I'd have to use
99.87% as a marker. And I don't want to remember such spurious
figures, since I consider translation of this string not important
enough.

>> Legalese is pretty hard to translate, and that's why I didn't approve
>> the change (i.e. it's likely to skew the stats).  And it's commonly
>> binding only if it stays in English (at least for GPL, even if we
>> generally mark such passages for translation).
>
> That's probably true, but then the question would rather be if this
> string should be marked for translation or not (you do ask to be
> marked for translation in 2.16, though).

Explained with the remark: "even if we _generally_ mark such
passages".  I am not a lawyer, and it is common practice in Gnome to
mark them, so I am simply not changing anything.

> I don't get this, what does make it mean that "our process is a bit flawed"?
> How do you detect string breackages today?

I watch one of the 100% (or nearly) completed translations for changes,
and check the string count in my weekly stats e-mail (I generally
check it only once a week), i.e. I basically look at

  http://i18n-status.gnome.org/gnome-2.14/top.html

and the less string freeze breakages we get, the less I have to
browse from there.

> As a [probably naive] proposal, what about making a pot file just
> after string freeze, and then generate a new one daily, and then
> compare both to see if there are changes? (comments should be out, of
> course)

It sounds fine, you are welcome to implement it: I can give a hint or
two if you need it.  :) 

(we also need ability to mark another revision of POT file as "frozen" 
one, since we do approve some freeze breakages)

It shouldn't be too hard to even add automatic mailing to one of GTP
spokespersons who'd have to do the investigation manually then. :)
I'll be happy to put it then on one of Gnome servers as well, and run
it as a cron process.

I don't have the resources (bandwidth to do full CVS checkouts, time
or desire either :() to perform such check manually. 

> I don't know what you mean with this, but many strings (maybe most of
> them?) are rarely seen (gconf stuff, tooltips, etc), yet if they are
> not translated, they will make  some languages be not supported...

Again, it's a flaw in our process: we measure "supportedness" only by
the string count in the stats.  Another reason to not allow string
freeze breakages, and to allow putting in some strings untranslated
which are rarely seen.

Ideally, we'd have prioritised translations, and we'd evaluate
supportedness only by most important messages (i.e. gtk+/po-properties
would be completely excluded, as well as most parts of
gnome-applets/po-locations, and many messages inside all the other
modules).

But we are not there yet :(

> Anyway, my point was that if you let a new string in, you should allow
> translators to translate it, else leave it out. I might be wrong
> though.

No, allowing it in is a service to developers, while not harming
translators (by skewing their stats, perhaps having their languages
end up unsupported): localisation won't be complete, but in practice
it's not important, since it won't be allowed for visible messages.
Or do you disagree?

As I said, there are many flaws in our process, but I don't have the
time right now to go around fixing them :(


Anyway, Guilherme proposed alternative solution, and I support him in
carrying it through. :)


Cheers,
Danilo