Re: [Gramps-devel] gramps' internationalization philosophy, if any

[Paul F. <pf....@gm...>]

You wrote more in your reply than I can understand.

And also commented on things I never proposed.

> (should we also translate bug-reports filled by the users? IOError, OSError)

I don't believe I was suggesting that many totally-parallel
gramps structures should be set up, with all bug reports
and comments to them translated into every language,
for instance.  Of course gramps development -- and code --
will be done in English, as it has always been.  After all,
while Python was written by a European (I think) he used
English words ("if" and "else" and "while" and "break" etc.).

Nor did I propose translating debugging output strings.
And since I haven't had a crash while experimenting with
LANG set to something else, I don't know if Python gives
a language-specific error message or not (although I would
suspect that it would, and I would argue it should).

> As pointed out: fully internationalized means translated keys ...

At no time did I propose translating the inner structure
and code of gramps itself.  Clearly there is no need to have
a dictionary's keys be in every language, since the user
will never see them.

> True, this will always work with english locale, but could generate some
> crashs on localized versions. ...

As I don't operate under a linux installed in a
foreign language, I am somewhat ignorant about the
distinction between a "locale" and a "language" as
all I do is set the LANG envariable.  But when I was
glancing at the gramps code that was its first choice
and it only seemed to look at other things if LANG
wasn't defined.  Am I wrong?  Will gramps fail if I
only change LANG and don't change some other
envariable?

> But localized CLI is not for 'Tante Jeanne (Aunt Martha)' and I guess that
> most french folks using CLI also understand english basics.

So are you saying that in your opinion nothing which
is CLI-specific needs to be translated?  That by
definition all CLI users are "power users" and do not fall
into the lowest-common-denominator group which gramps is
aimed at?

If so, while I respect you opinion I disagree.  But it's a
matter of opinion and I don't expect people to be able to
convince other people of the validity of their opinions.

> As said, there is a general way and to call around 2000 time gettext module
> into one Gramps session provides more confort but less free available memory
> and speed. Maybe strings are loaded twice (or more on some textual text
> reports). Internationalization is just an additional feature.

I haven't the slightest idea what you mean.  If you are saying
that gramps will be inherently slow due to its underlying structure
I will take your word for it but would claim your argument is with
the original coders, who chose Python and not something like C.

I don't follow everything you said about "localization" as opposed
to "internationalization" but if I understand correctly gramps has
never aimed to be fully localized and is satisfied with a basic form
of internationalization.  I don't see code in gramps at the moment
which distinguishes between the French used in France and the
French used in Belgium.  Nor do I see different date and relationship
handlers for the German used in Germany and the German used in
Austria.  (If gramps ever gets enough of a Chinese audience it will
probably need to distinguish between the "traditional" and "simplified"
characters but I am not Chinese; it's only intellectual for me.)

> Note, I do not know how CLI retrieves these names !
> Maybe via *.gpr.py ? which are also used on plugins manager (GUI).

Yes, that's where those translated report names come
from, the translated strings in the *.gpr.py files.  (Note that
some are not flagged with the "_" and are therefore not
translated.  Look at Outils => Deboguer for instance.  I am
assuming they are not translated by design, a conscious decision.)

So, in summary are you saying I should submit a patchfile or
that I shouldn't submit a patchfile?  I would argue that it does
no harm to submit a patchfile since after all I cannot add it to
the SourceForge repository.  If no developer sees fit to add it
(as has happened on all the various patchfiles I have submitted,
I think), then nothing will happen to gramps as a result.

Thank you for your comments.