Re: String addition to gnome-terminal

[Josep Puigdemont <josep puigdemont gmail com>]

Hi Danilo,

On 17/02/06, Danilo Šegan <danilo gnome org> wrote:
> Hi Josep,
>
> Today at 17:18, Josep Puigdemont wrote:
>

> > > On 17/02/06, Danilo Šegan <danilo gnome org> wrote:
> > > I'd rather you add them as untranslatable strings for the time being,
> > > and mark them as translatable in 2.16 cycle.

> > This is like allowing to break string freeze and not giving
> > translators the chance to fix it...
> > I think the decision should either be to leave the string out, or to
> > officially break string freeze.
>
> No, it's not.
> 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.

>
> 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).

>
> Of course, it means that our process is a bit flawed, but until
> someone comes to fix it (i.e. devise another way to detect string
> freeze breakages), this is the best I can think of.

I don't get this, what does make it mean that "our process is a bit flawed"?
How do you detect string breackages today?
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)

> Using something like gettext() instead of not marking it translatable
> at all would not be caught by xgettext, yet it would allow those
> interested to translate them themselves and include translated bits in
> PO files.  The same reasons that were given by a developer ("they would
> rarely be seen, so it's ok to have them untranslated") applies here as
> well.

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...

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.

Regards,
/josep