[IPython-dev] internationalisation and translation of ipython

[Nicolas Pettiaux]

Hi Fernando,

THanks for the long reply.

> Thanks for starting the discussion here... As Aaron indicated (many
> thanks BTW for that insight, it's *extremely* useful!), this is a
> tough job,

I know it is

> and one that is very easy to fall out of date.  So I would
> follow a few criteria in any attempt in this direction:
>
> - focus only on localized, high-value targets: the notebook UI, the Qt
> console UI, the magic docstrings and the main usage.py strings.

this is exactely what I want to start with on work on now. If we
succeed with that, I would already be very happy, and then only we
could move on to something larger (more documentation and website)

> - I would, at least for now, leave the website alone: it's too
> dynamic, and for better or worse people survive with a few websites in
> English.  We could add to the main website a summary page in other
> languages, that we would not attempt to maintain in perfect sync with
> the main site.  This would serve as a reasonable explanation of what
> ipython is to speakers of other languages, and would tell them what
> parts they can expect to see translated and which ones they can't (for
> now).

Yes, I see it that way too. A summary of the website, with the
unmoving parts translated, and maybe only the annoucement for the
release and the new features, much as the LibreOffice project does.
This would ba adressed as said, after the first part, unless I find
people to tackle this task.

> - focus only for now on high-value languages that have a decent chance
> of being maintained in the long run: Spanish and French.  I understand
> the value of other languages, but this is simply a matter of resource
> triage and impact. For example, most Dutch/German/Scandinavian
> languages speakers tend to at least read English very well, which is
> not necessarily true in Spanish.  If we get to a state where we have
> these in really good shape, we can consider others. And before anyone
> accuses me of Western-centrism: if we reach that point, we'll already
> be doing better *than Python itself*, which has vastly more resources
> than we do and whose docs aren't officially translated to any language
> that I can find.  So yes, it's western-centric, but that's simply the
> reality we come from.

Yes, after the internationalization (i18n) effort that is related to
the code (as per use of gettext), the localization (l10n), that is the
translation itself, would have to be taken separately.

I can only work for French, my native language. I believe you are
right. The young Dutch/Scandinavian/German do have a command of
English that is good enough. And if they want, they have active
communities that can tackle the problems of the translation (t10n) if
they want. But I will not take any energy on that.

> - If you want to take this on, you'll pretty much have to lead the
> effort yourself.  Other than providing you feedback by reviewing pull
> requests, I'm afraid right now I have zero bandwidth for this, and
> it's not something that has ever come up until now, so I suspect the
> 'available effort' from others may also be low.  But it's also
> possible that if you lead the way, others may join in and help, after
> all this is the kind of task which, once the basic machinery is in
> place, lends itself well to distributed maintenance even by people who
> may not know how to code.

I know that I would have to lead the effort. I am not anymore an
active developper and this is an activity that I am ready to work on:
get back to the code to add gettext structure to allow for i18n and
then work on the tool chain to have a good setup for the t10n.

I am now looking closely at the tools and process that the LibreOffice
and Mozilla projects use, as well as other established l10n project.

See for example http://translate.sourceforge.net/wiki/guide/start and
http://www.africanlocalisation.net/sites/default/files/FOSS%20l10n%20guide%20-%2020110214-en.pdf
.

I am also in touch with professionnal tranlators who have just created
a foundation to help with the t10n tools to assist.

> - it will be very important to focus on implementing this in a way
> that is as unobtrusive as possible to the main development in English.
>  I know next to nothing about i18n other than 'use gettext', but I'm
> sure that if the setup makes regular development in English
> substantially more cumbersome, you'll get tons of pushback from the
> main developers.  Again, it's a matter of balancing priorities with
> limited resources: people try to squeeze whatever IPython development
> they can typically 'on the side' of otherwise very busy schedules.
> That's why we insist so much on tools and workflows that are very
> fluid (github, our very streamlined branch management, our tools/
> directory, our website/docs setup that is now being adopted by others
> in the scipy community, etc). Anything that brings friction to the
> everyday work will be (rightfully) seen with very skeptical eyes by
> the core devs.

I completely agree with that.The i18n activity must be completely
compatible with the easy developpement in plain English. It is with
gettext.

For the developper, the use of gettext is nearly limited to

* insert something like "import i18n.py" or "from gettext import
gettext as _" at the beginning of the file,
* wrap the visible strings (window titles, dialog titles,
notifications, labels, button labels and so on) with the '_()'
function.

I suppose that this is doable and would not be obstructive for the
coders. Please let me know.

I am looking at the process for javascript, but I suppose it is not
much different.

Then the l10n process starts, with its own tools, but this is *not*
related to the code, and can work completely independently, with its
own tools, process, workflows and people.

There is a quite good video on the subject of i10n
http://www.universalsubtitles.org/en/videos/Q06kJR9g5IHq/en/252681/

My plan is to let *you*, the coders code, and start tackling the work of l10n.

> And given that ipython's focus is scientific work, and
> that for better or worse scientific work pretty much *mandates* a
> command of English (I know what I'm talking about: as an undergraduate
> in Colombia in the early 90's, many of my *textbooks* were in English,
> so we didn't really have an option),

so were mine as an undergraduate in physics, for the French speaking
Belgian that I was. It is still the case.

> our English bias will remain
> there for the foreseeable future.

indeed it is.

But if we want the beginners to start with ipython, IMHO, some
localized help must exist, as well as tutorials, subtitled videos ...

By the way, once the English videos have been subscribed in English,
which could be useful also for English speakers who are either deaf or
if the speaker has not a very good pronunciation, for example because
he/she is not a native English person (which is about 92 % of the
world population), the subtitle can easily be localized either with.

See for example the initiative http://www.universalsubtitles.org/

I am wondering if and how all the tools of gettext l10n can be used
for l10n of subtitled videos. I am looking into this subject to.

> I hope the above doesn't sound discouraging to you:

it is not.

> I'm simply trying
> to give you a realistic assessment of what will be needed, at least
> from what I can see at this point, to make this happen.  I'd rather do
> that than give you a rosy but falsely encouraging picture.

This is the picture I have myself, and I know where I am starting and
where I want to go.

> In summary, I think it's a worthwhile task, and if you are willing to
> lead the effort and make progress on it, we'll be delighted to review
> your contributions.  And obviously, if others on the list would like
> to participate on this particular effort, by all means join Nicolas!
> This is the kind of thing that may seem a bit daunting for one person,
> but where if two or three people get together, significant progress
> may happen before you know it.

I plan to write some small proposals as soon as I can, once I will
have got the process I think are best to propose you.

I would with pleasure work with as many of you as possible, and get
back to the code through this effort.

Thanks for your interest,

Nicolas

-- 
Nicolas Pettiaux