This talk will be in French,
so I apologize
After much debate, we decided to settle to French
because we present the French localization
but I can announce right now
that I will subtitle and translate this talk
as soon as possible, so if you’re interested
come check in a few days and you'll have subtitles.
Now I can switch back to French.
We're going to introduce to you how we localize Debian.
First, I will explain what localization is.
It's a word that we do not hear often
except when you actually do localization.
Roughly, it's the same as translation
but it's a little more than just translation.
Besides simply translating…
[mic stops working]
Thanks.
So, where was I? Ah yes!
We do not simply translate in a litteral manner
from English, in this case, since it's the original version,
to French
we also try to adapt
to the french, or French speaking, context and culture.
It's abbreviated in l10n
That is localization, one "L", 10 letters, then a "N".
So don't be surprised if you see this.
This concept is really close to the internationalisation, or i18n,
which consists in preparing content so it is
easy to be translated, localized, in other languages.
So, why do we do that?
Simply because it allows Debian
to be accessible to users who don't necessarily
speak English.
It's a good thing, since as the Social Contract says,
users are Debian's priority
but we also forget to say that it means
current and future users.
Yet, to attract new users,
there is nothing worse for mainstream users than to bump into
a system in English.
You may know the saying:
When a computer is pissed off, it speaks to you in English.
We know that it is not the case, but for a mainstream audience it is,
so it's important for us to have a system
as internationalized as possible, and so in French as well.
It has also benefits for yourself
and I believe it's important to state that
for those who would want to contribute
because it allows all contributors
to learn new things
by discovering all the aspects of the Debian Project
because the translation work is really diversified, as we'll see later.
It also allows you to discover upstream projects
and how they work
and it allows you to contribute at your own pace, because
you can participate calmly to this or that thing
without doing it continuously at the beginning, and keep your pace.
Last but not least, you can improve your english
because when you translate, your English can becomes a little better
in the end
at least when it comes to write and understand it.
So you can improve your English, which is not negligible.
And all of this is thanks to the vast scope of translations
as we will see now.
So, what is our scope.
First, packages.
It makes sense, as it's at the core of Debian.
We translate native packages developed
by and for Debian, like dpkg, aptitude,
all those packages.
We also work on debconf configuration screens,
screens when you install packages,
for instance, with exim.
When you install this package, this screen is prompted
to ask you
« Do you want local alerts? » etc.
This configuration is by default in English.
What we do is translate it.
You can notice that it's…
Here, the English text spans on 3 lines
and once translated into French,
it spreads on 4 lines,
because French is very rich (and verbose)
so it will take more place
on the configuration screens.
So, sorry if they're too big, we try as much as possible
to keep them short, but we want to remain faithful to the source.
We also translate announcements.
All the announcements sent to the
debian-news-french mailing list
such as Debian releases, DPNs
and all other announcements.
Evething that you see on the list goes through the team
Also, the web site.
There are 10,000 pages on the web site.
That's a lot
and 90% of it is translated (in French).
Some big contributors to it are in the room.
There is the static part of the website, the one we usually see,
the homepage and all the pages that do not change very often,
but there are also the publicity announcements, security (DSA and DLA) advisories
and that makes a lot of pages
We discussed this topic yesterday during the l10n team sprint,
that's between 300 and 600 new pages per year
so it's quite big, one or two pages per day.
This work could be a little tedious
so we try to find some novelty when doing
those translations.
Recently, we also translated the DPL canditates platforms.
It was like a mini sprint for the team
several members contributed for this
to try to provide all contributors
people who can vote in Debian,
a French version of the platforms
and also the results at the end of the vote.
That's a pretty intense work during a very short period of time.
We also translate the documentation
because it's really important for users.
Of course, we translate the documentation which comes with
Debian-specific software.
An other subject that will soon be topical,
we're currently translating the release notes.
Everything you will find when installing Buster,
if you're interesting in having a preview of what to expect,
you can come help us.
I, for instance, know all the potential issues I'll encounter
when I will migrate, and that's interesting to have such a head start.
But we also do all other docs, like the Debian Developer's Reference.
It's a good way to learn more about
how packages are built and what you can do.
Also, I've been told that there are package in Debian
that's a lot (bad pun in French)
And those packages have a description.
Before installing something, you can look at
what to install
you type "apt search",
have some results that interest you
"apt show" to look what it is.
And then, you have a short description and a longer one.
What we try to do, more or less successfully
is to translate all those descriptions.
As you can see, there are currently about 59,000 descriptions.
In French, we have… 18000
Well, about 19,000.
There's still work to do, because like for the web site,
It's a moving target, because when packages are uptated,
their descriptions can get updated as well.
Currently it's a little calmer because of the freeze
so there are less updates
but we know that as soon as Buster is released
everybody will restart to send stuff to unstable
and we'll be completely overwhelmed.
We'll show you the translation and review process later
but we give details here for package descriptions because
it's done somewhere else.
There's a tool for that, DDTP, and its web interface, DDTSS.
That's a thing for which you can spend only
5 or 10 minutes a day.
You register, go check translations in progress,
review one or two of them,
say "Yep, it's ok", "Nope, forgot a semicolon there"
and you're done. Then, if you're motivated
you can spend more time on it, as you wish.
Even if we'd like to, we do not translate everything
and we do not try to achive that, in particular
we do not work on software already translated upstream
because that would be redundant
and we're already quite busy with what we translate.
That's the kind of software not translated by us
mutt, firefox, wget… That's a lot, actually.
But, sometimes, there are exceptions to this rule
for instance, "anattended"
It's not a native Debian package,
it's hosted on Github.
Recently, I uploaded its translation directly in Github.
In this case, we bypassed the usual
Debian process.
We, translators, still used the mailing list
for coordination, reviews and so on,
but after that, we do not develop those packages
We're happy to use them in Debian
Manpages is also a good example, because there's a lot of work
for manuals.
To give you some details about the manpages,
a cross-distribution project, called perkamon
aims at translating the manpages into French
It had less success recently
it has been a lot less active
and one member from our team
reached out to them and asked
"How is it going? Do you need help?"
And I believe that they simply gave him control over the git repo
and that's it.
And since I helped him a little.
He also gave me access to the git repo
and so, without really wanting it, we became our own upstream.
This kind of things happen
so be careful when you asked people for news,
sometimes they just give you the keys.
If only it was the only difficulty… but there are more
That's one of them, indeed,
that a l10n can encounter
If fact, this topic of scope, where to start, where to stop
is a first difficulty
Another one is also the debates about
the cohesion of translation
because, of course, since we're a lot… well, not that much
but still, several people
everybody translates with their own sensitivity
and there are also some heated discussions about rules in French
where to put dashes, where to put non breakable spaces,
medium dots, and so on.
Of course, every time the team settles on something
it also means working to keep the whole consistent
So cohesion of translations is a real issue
in particular with the review processes
and the number of things that we have to translate
it's a real challenge.
For instance, when we translate packages
a "fun" thing to do is
to make the jargon of specific fields your own.
For instance, it's really nice to translate packages about
astronomy, maths, biology, etc.
It's especially nice when you have never seen that in your life
you read things…
In OpenSSL, I read something, "elliptic curve"
Interesting, it's translated "courbe elliptique", apparently.
Don't ask me what it means, I have no clue.
But at least we translate.
And there is also a real challenge about the scope of translations
in the coordination part, because there can be
a gab, from time to time
between the translator
the package maintainer in Debian
who does not necessarily care about its localization
and upstream developers who can also expercience a mismatch
between the upstream version, the version in Debian
and the version translated by the translator.
All of this requires coordination on many levels
and this is not always an easy task.
That's it for the difficulties that we handle mainly by e-mail
That's how we keep track of everything.
We have a bot which analyses e-mails subjects
that's why they have a specific syntax
that we'll see later.
We have to monitor translations,
know at which stage of the review process they are,
that's the purpose of the bot.
It shows us when a translation needs to be updated,
that's why we communicate using a language that
it understands, it allows us to track translations more easily
from our mailbox
which is very convenient
and to remember the status of our own translations.
It requires a series of steps that we can detail
that translate into some kind of codification
which looks a little complex, at first sight
but then, let's look at it together, it's not that hard.
All you need to know
is that there are several stages in the process,
one where we say…
Ok, do it
Alban is switching screen, there.
Here's an excerpt of what happened on the list in April
I think… yep that's it.
At first, we had a slide to explain
the meaning of all this,
the codes that you can see at the beginning of subjects.
And then we thought "It's too much, we're going to scare them away."
"Let's show them the list instead."
On second thoughts, I'm not sure if…
It's worst, actually.
Typically…
There, you have a simple one.
There we go.
So, usually, the review process starts with a subject
in RFR, Request for Review, and in this one,
Jean-Paul said "I've just updated the translation of ddp.wml"
so, a page about documentation
"What do you think of it?"
In this case, he didn't have an answer, so he sent a LCFC later
a Last Call for Comments, saying
"I'm going to stop this review soon if nobody has comments."
And since nobody did, he concluded "I consider it's ok,
so this review is DONE and I stop this thread,
the translation has been approved."
Just to reassure you, maybe nobody answered him
but usually, when we do not spot errors during review,
we answer off-list, to not add to the already large volume of messages
and say "It's ok for me."
An example a little more… Oh wait, it's the same.
What did happen? Was there a problem with the pseudo-URL?
You've got two there.
Ok, no big deal, let's pretend it's a different thread
it works the same.
So, RFR again, "I translated this or updated this translation,
what's your opinion on this?"
There, an other contributor answers
"You forgot an 's' here" or "You used a dot instead
of a semi-colon." or something similar.
The answer is then "Yes indeed,
here is an update of the translation
this is a new call for review."
Someone else says
"Wait, you missed something else."
And so on, until after a few days
we think we waited long enough
or got enough feedback
so LCFC and then the process is complete.
Could you find a MAJ?
In this case, when the thread starts with a RFR,
it means the translator took the initiative to look at what was missing
and said "Well, this package, this page that I maintain is outdated."
or "This announcement has been published, I'll handle its translation
and do it right now."
But sometimes, like here
It's actually a "Re:" for a MAJ.
No, it's ok, we can see it.
We also do coordination, and from time to time
we send MAJ messages so say
"Hey, you maintain this page or this package or this doc.
I noticed that it's not up to date anymore,
so here's the new version to translate. Do you want to take care of it?"
Then, the person either sends an ITT, Intent to Translate,
"Yes, I'm willing to pass the torch to… well, myself actually.
Give me some time, I'll update the translation."
A little while after, a RFR is sent to start a new thread
and so on.
If the maintainer can't do that, he simply answers "I can't."
and the translation is available for someone else to pick up.
All the rest here is a complicated pseudo-URL.
I think that now we all manage to understand them.
It's mainly to help the bot which crawls the list
and updates coordination pages to say
"This page, this manpage is currently under review."
That way, we can have a good overview
and not interfere in ongoing translations.
What's interesting with MAJs,
is that we do not necessarily send them
to team members that we know
and who contribute on a regular basis,
we'll send them a ping, a short message
"Hey, don't forget to update this and this packages."
Here, it's really for people who have stopped
or are just MIA.
Like Thomas said, this MAJ is the ping and a waiting period.
It allows us, in the statistics pages,
to know which translation needs to be adopted.
We reached the maintainer once, twice,
usually it's at least twice
and then we know that this translation is available for adoption.
There's also an interesting detail here.
There's a DONE to close a thread.
The DONE is because we are going to,
well, the person who sent it, will push the revision themselves.
There, it's wml, so it goes directly on Salsa.
The file has been pushed directly on Salsa by Jean-Pierre.
When we do not have the needed permissions to do the upload
we close the thread with a BTS.
Here, Quentin, who's in the back of the room, sent a BTS
because he sent his package, his .po file in a bug report
directly on the po-debconf package
and then, it's up to the package maintainer to include it
into its archive.
It's a small nuance in the way to close threads,
it's either a DONE or a BTS.
Either we do it ourselves or we delegate it through a bug report.
So, how to contribute.
Do not worry, it's very simple.
First of all,
if you see a mistake in a translation,
really anywhere,
please report it to us, or if a translation is missing
while it would be really useful for users
if it was translated.
We try to do our best.
The goal is really to have
a base installation as accessible as possible
translation-wise.
So, if you do a fresh install,
the ideal result is to have everything translated.
If things are missing, please let us know.
Also, if you see mistakes,
send us a message on the mailing list
debian-l10n-french@lists.debian.org
you'll have an answer very quickly
or use IRC, we'll answer even faster.
In any case, there are quite a number of active people.
Within a day, you're sure to have an answer,
at least to say "We'll handle that."
And it really helps us.
It really is an important contribution.
Otherwise, to really play a role in translations themselves
subscribe to the mailing list
and once you did it,
you can start to read and proofread all the messages.
All the subjects that Thomas showed earlier
will start to make sense to you.
At first, I agree that it's not obvious.
Some web pages explain that really well.
But when you get it, you get it.
When people start and do not know, it happened,
it's always difficult at first.
So, proofreading, following what happens on the list
will help you to get a grasp of how it works
and then you'll be able to review translations
take someone's translation, have a look at it
fixing mistakes, if any,
directly in the file
make a diff, send it to the list
and then, the translator who started the thread
will apply your patch to the translation
and send it in a RFR2 to start a new review process.
Or you can also translate package descriptions
on the DDTSS site.
So it's either the list or that,
but the list is kind of cool, because
you communicate with people, see who's in the list,
really nice people.
It's nice, it's the first time we were so many to meet, yesterday.
It's interesting.
So, proofread, and of course translate.
It's ok to wait a little to see how it works
see the little habits to have
where to put non-breakable spaces, before question marks
colons, and so on.
All these small details really disturbed me at first
it's indeed difficult, or
"No, don't use this wording, because if you do it here,
we'll have to change it in 40,000 other packages. So please don't."
So look at things from a distance at the beginning,
help by doing proofreads, that's a really good start,
it helps a lot.
And after a while, when you'll see TAFs
you'll throw yourself into it and say
"Ok, I'm ready."
If no TAFs are sent, which can happen
when there is no update or we don't
propose such updates,
feel free to declare yourself on the mailing list and say
"I'd like to help, how can I do?"
We're here to help you
and it's with great pleasure.
If you're more interested in short term contribution
or less time consuming contributions,
packages description can be a good start.
I've never done it yet
we talked about that yesterday, and also did a while ago.
Let's finish quickly.
Just for posterity, when you'll watch these slides and wonder
"How can I contribute?"
here are some links to monitoring pages.
Those are basically the result of what the bot sees on the list.
Do you want me to show one?
Yes, you can show one as an example.
Don't be scared, it's really colorful.
Debconf screens for instance, it's really simple.
And it's a good news, because it's often from there
that you'll intuitively get the pseudo-URLs you just saw
in the mailing list, they are actually here.
So no need to rack you brain more than that.
It's not done by the coordinator using the attachment,
it's done via the mail subject that he wrote,
and you can see what match with the URLs
that go after RFR, TAF, ITT, etc.
What you can see on this example is that we're mainly in the green
and that for two out of the three examples that are not green,
we're already on it.
The grey one, down below, is 0% translated
just because it's a new screen
and there's already a bug report
with the new translation, and for the one at the top,
there's also an open bug report
so we just need to take care of x2goserver,
Jean-Pierre (x2go's translator, in the room), we're waiting!
To contact us, you can send an e-mail to this address
you can come on IRC, obviously.
Soon, maybe, you'll even be able to report bugs against a metapackage
we're thinking about making one for french localization
to make bug reporting easier for you
when you use Debian in French.
And because we're aware of the real stake about humanization,
that is, it's really hard to put you into documentation by yourself.
In Debian, we're used to that, but some people cannot.
Some of them take 15 years to make it.
I'm not thinking of anyone right now.
What often unlocks the situation is to meet in real life
like what we're doing here,
or on Debian France booths at FLOSS events
where it's often the l10n team who comes,
and so it's often a nice entry point.
Come talk to us, ask us how it works.
Come ask us to explain this jargon
because we have our own.
It will be with great pleasure and since we're here today and tomorrow,
come, do not hesitate, come, come
and we'll answer to all your questions with great pleasure.
Now you know that there are tens of thousands,
maybe hundreds of thousands of things to translate in Debian.
So every contribution is welcome
because the team is only made of a dozen of people,
5 of which are really active.
So, clearly, every support, whatever how small,
even one package description or two,
even simple reviews, it's…
Every support is welcome.
Don't forget that there are other translators in the room,
they're hiding, but they're here with us.
Some of them are among the most active ones.
That's it, thanks.
We have time for some questions.
We also take questions in English if you want.
[Question] How much time does it take to… say, immerse yourself
and be able to start small translations, at the beginning?
[Jean-Phillipe] 15 years?
[Alban] If you don't dare come to the list,
it can take 15 years, indeed.
But if you go to the list, come meet people,
talk to them,
even send an e-mail to introduce yourself,
say "Hey, I'm here."
I didn't do it at first,
I didn't introduce myself when I subscribed
so I followed the list for several months.
I was very quiet, wondering
"Should I do a review?"
Then I threw myself in, started my first review.
You learn how it works, bit by bit,
and the faster you make contact, the better.
[Jean-Philippe] When you proofread, once you've understood
the e-mail subjects syntax for the bot
and after a few reviews, for a couple of weeks
you can quickly become operational
be it only by doing a package description.
You get reviews and then you're good to go.
It depends on yourself and the time you want to invest in it.
In my case, I started with debconf screens
which are really simple.
It's really short, files are easy to translate.
It's really good for a start
whereas take a full package, or the full translation
of the platform of a DPL candidate,
might not be a great idea.
[Jean-Pierre] Juste to complete, what we totally forgot
while preparing this talk, is that we also translate the wiki,
and we didn't mention it.
There's a lot of work to localize the wiki.
It's not monitored, it's a wiki, you just go and edit.
Nothing is reviewed. There has been one or two pages
that went through our review process, but otherwise there are
hundreds of pages to translate
if you think that they'll be useful and clear
once in the appropriate language.
It's a lot of work.
That's how I started, doing wiki, wiki, wiki
because it was open, maybe less intimidating.
There's no proofreading, it's even less intimidating.
There are only revisions, which are not the same.
[Alban] The first time I edited the wiki, I found it interesting
to see and update.
Because you take the source, first,
instead of just translating, you test the wiki page, read it,
notice mistakes.
Then you fix the upstream version
and translate it afterwards.
Thanks a lot.