Okay. Hi, folks. Thanks for this talk. I wanted also to thanks for them and the organizers
here for this dev room because I'm very happy that the translation to make part of the topics
in such an important event. So it's a very good news, I think. Well, I wanted to propose this
talk because, well, personally, I have started Free Software in 2004 and I have done some
contributions to the Debian project for a long time, but I only started translation in this project.
I have started that since 2018. Well, I told myself, how could we help new contributors,
new users, new potential commerce, to help the translations team with the capabilities that
Debian can provide for them and also with what Debian can't provide. And it's also what we're
going to see and we're going to see why it's not so easy, actually. And so I told myself also,
well, I'm sure some people think that, oh, but why Debian doesn't use modern tools such as wood
lights such as modern for editors or things like that. And so I had the thought about that.
And to myself, well, why not share that with people to understand why Debian works like that
and how a user, a new user could contribute with this way of working and without no problem and
without problems with satisfaction. So the example I take is, of course, this is a French
translation team because it's the team I know the best, of course. It's a very small team.
And it's a very, very small team. As you see, there are few people. There have been people
for a long time, but it's never a team with 10 or 20 persons. No, it's a very, very small team. And
also it's not a team which have a lot of technical skills. I mean, there are some Debian developers
but which are technical, they are one or two. And most other Debian developers of this team are
not uploaders. That is, they don't or they are not considered or they are not considered themselves
able to do uploads of new packages or things like that. So it's not a technical team. It's
really a translation team and not a technical team. And amazing results are produced by this
team. I mean that it's a very small team but very amazing results exist. For example, we have
all the things we translate and we know that we are the third language best translated in the
project. And when we see the amount of work which is needed to get that, I think the team may be
very, very happy. And I can say it because I don't make part of all the team and I don't make part of
these projects. So congratulations to other members of the staff. So the websites, the installer,
all the things which are translated from up to nearly 100%, the Debian package descriptions
which are not translated, of course, very much. But the most important are translated and it's
very important for us also to enable French users to get the package description, at least for those
they have more chance to use. So I think it's very amazing results when we know the real size of
the team. Then we work for a project which has been a very long history, as you know. The first
message, I was very happy to discover that preparing this talk. The first message of the
Debian translation team for French is in 1998. It's very old. The world has changed very much
since this year, of course. And in particular, the technical world. So of course, the process,
the workflow is made based today. And we have web pages, web pages which enable to have a tracking
of the situations and to have some statistics and to have some information. Some bots who
automate some things and also some statistics. And some made-based to have a workflow between the
members of the team to ensure that the translation has a good quality. The tools, as I said, are
made-based. That is, on the Debian mailing list, the Debian mailing list for the team, the French
in the French team, there is a bot who is able to receive the topics, the subject of the messages
sent by the member of the list to pass them and to produce statistics from this and to produce
some status of the packages or the pages we are translating. So it's very important, of course,
because it enables all the members of the team to know if, for example, someone is working on
something or the status of something if it's up-to-date or if it's not up-to-date or other
information like that. So the thing, of course, is, well, what can we do with the made-based
process given the number of things we have to do? Well, we track the changes. So it's very
important. We can know the status of the translations. And even if we've stopped working for a long time,
we are able, easily, to join the team again and to know what's the situation and what about
the situation. There are also coordination pages. So with the tracking pages, which enable to do
that. So we have the announces for the websites. We have the package translated via profiles.
Packages are translated because they are classical programs. So they have this, they use GetText
as many programs today. Also descriptions, also depth course screens. Depth course, of course,
the screens that the user gets when he's installing a package to set some configuration at the
installation time. And the website, of course, which is a very high work. So I think the problem
of the Dibian project and the reason for which it's probably very difficult to use automated tools
is that there is a lot of formats which are used as inputs and also outputs.
I mean, inputs, we have at least a packages description database, which has some formats. I'm
not sure I know what it is about, but it's not a format such as po-files or HTML files. It's another
kind of format. It's a database. HTML, of course, and the po-files. And for the outputs, we need to
produce, of course, some translations, some classical, typical translations we find in any other kind
of programs of free software, but also the websites, so HTML pages. And various other formats. So
it's not so easy to ship that in a kind of automated tool because it's really a really
quite big task of administration to set that initially. And I remember that in the team,
we have not a lot of technical skills and we are not very numerous. So we can understand that we
prefer going out with males, even if it's probably not perfect, but at least it enables people to
work. While changing to another kind of tools, even if it would have benefits about the interface
and the user experience, it would be really a challenge, a very important challenge.
So changing is very difficult. Is it a good idea also? It's an idea that the team wonders sometimes.
Is it a good idea? We wonder that in particular because that's right, there are not a lot of
new contributors if we have a look annually. However, when people come and contribute to the
translation project in Debian, they stay with us. They don't leave us. So probably it means that
once we manage to adopt the tools, to adopt the process, we like it and people are comfortable
with it. So even if it's not modern, once you take the care to learn it, at the end, I think we can
be comfortable with that. In particular because, well, we can get things offline. In particular
because we can take the poll and do some stupid things without being sure you are not breaking
all of the process or you are not breaking all the translation of others. So I think it gives
some benefits that people are happy to have. And that's the reason for which moving is difficult.
Because people are happy and we are not absolutely sure that changing that would be a good idea.
And when we try changing, for example, we try to migrate the server for the package description
to another server in Debian, it takes a year and it exhausted some people. So I'm not sure it's
the best idea we can have, even if this migration was really important. But imagine if we should
have a migration with more impact and more things to address. So instead of changing things,
I suggest to propose to the users, to the new contributors, a kind of approach
which enables everyone to, well, let's discover the project. Let's discover the interactions
you can have with the team from the easiest to the most complex. And from this basis,
do your way, follow your way. And the first step, for example, is for, and also, yes,
on every step on the way, the idea is also to have two kind of status. The two kind of
status, we are going to talk about that again in a few minutes, but it's more or less, okay,
either I am a reviewer and I start to understand all the conventions of the team, how the team
works, et cetera, or I become a translator myself. And of course, I start to contribute
with other translators. So it's a way to contribute for the rhythm of everybody.
I suggest that the first thing you can do if you want to contribute, because again,
there are not some tools which are attractive, but also start with the easy thing. And translating
the wiki pages of Debian, for example, would be an easy thing because much people love to use a wiki,
it's not so difficult to use. And using a wiki today is, well, okay, you take the page,
you cut and paste the contents, you create a new page on the French wiki, and well,
and it's done. So it's not so complicated to do. And it's the first step which,
well, creates a kind of initiation training for the translation. We saw so much consequences
for the project because it's not an official resource, but it's a community resource. It's not
a resource maintained by Debian members, so it's not a big problem if you do some mistakes or
things like that. The next step is probably the package descriptions. It's interesting because
there are a lot of responsibilities because, well, package descriptions are what users will see on
their screen when they will see it for a package. However, the interface is simple. It's a web
interface which is, well, there are some conventions, there are some rules to have, but there are also
a first contact with the translation team. And it's something which is important because we have
people who review what you're doing. So you can do what you do, what Debian used to do. And for
example, if you try to translate some things like that, but Debian is used to translate
differently, you will know that. If you're not compliant with some kind of syntax or kind of
a way to introduce things, it will be said by the member of the team. So it's a first responsibility,
a first contact with the team, but it's a simple interface without needing to understand something.
So I think it's very interesting for that because it's a good point of beginning and
especially what I like in the package description tools is that it's very short. At least you
take some packages, such as latex, or of course latex, when you start translating the description
of latex packages, it's less fun. At least sometimes 2,000 lines for a description.
It's somewhat difficult. But if you translate some more
typical packages, it may be very short. And you can do one package a day, for example. So you can
do really at your rhythm, to learn at your rhythm, and not, well, with a minimum follow-up also.
So I think it's the first step, which is very interesting. The next step could be the
depth course screens on your way of a newcomer. So depth course screens is another thing because
now you'll have to post your translations proposals on the mailing list and to go in the process.
So to understand the virtual address that we made in the topic and the subject of the message,
to be sure that the robot is able to understand what you're doing and to report that in the
following, in the tracking stats, in the tracking tables. So it's a bit more difficult, but well,
you start having an experience of the Debian ecosystem. So we can consider that maybe you're
ready to understand that. Maybe you will meet someone physically. We will explain to you how
things work. And, well, depth course, okay, you are going to now intend to translate requests for
review, last chance for a contributor for review. So you are going to really come in the process,
to come in the Debian process, and to start contributing to really important things also.
And it's the first responsibility in the process of Debian with the mail, working, etc., etc.
And once you are completely comfortable with that, so the process is also here with coordination
of the packages, with the messages which mention their status, and once the mail is received,
of course, you can translate your things, you translate your profiles with your own editor.
With your own editor, why not on WebLate? Because I saw that WebLate can become a
dictionary of translations while using its own editor. You test the results, you also can do
that. You report when you finished and when the team is okay with your translation. You report
the bug to upstream, to the package maintainer, sorry, so package maintainer, and it puts the
profile in the package. And the benefits of that is you use your preferred text editor, as I said,
or also your PoEditor, PoEdit or localize as some editors on KDE which work very much for that,
to identify in particular the fuzzy strings or the translating strings.
Yes, because I forgot to precise some important things also, is that if we should use some WebLate
interface on something like that, there is another problem for some contributors like me,
is their accessibility problems. So it would prevent persons to contribute due to accessibility
problems. With this method, and like you can use some users, personally I use Emacs with GetText,
it's easy because it's in text and there are not problems related to accessibility.
Well, once you are comfortable with that, maybe you'll want to contribute to the
effort of the Debian community to contribute to main pages. Map pages is a big project,
2,000 pages about, and a lot of updates, so it's a big project. But the good thing is the method
is the same. So you clone the Git, you translate the profiles, you are on the mailing list with the
topics, the virtual topics, to follow the process, and when it's finished, you commit,
or you make someone in the team to commit. So you know the process, you know how it works,
you know the conventions in Debian. So now you are able to contribute to any project based on
poll files, even if it's not some, well, some packages themselves, but you can do main pages,
you can do package description, you can do package, Debian packages themselves,
so it becomes for you easy to contribute because you understand the process,
and also the human beings in the community. Well, the benefits of the main pages is that
well, just translate and discuss. You don't have any maintenance to do because German team does that
and does that very good. So it's a very, a new area, which is accessible for everybody,
and which is very cool to use. The next step, and it's useful for the community, of course,
because as you know, main pages, Debian translates that, but we don't translate only for Debian.
We translate for all the communities because main pages are used in all the distributions.
So also this translation is a way for you to contribute for all the community.
Then you have documentation, the Debian specific documentation. So related to the Debian software,
we have the release notes, of course, we have the Debian developers reference, etc., etc.,
but also now it's only poll files. So it's not so difficult to understand how it works and the
process to have a review and to have a quality assurance by the community of the translators.
And packages, same thing, in interaction with the community, we can also now translate all the
things. According to your time, you will choose one of these projects or just translate for one,
two, three, or all those projects, according to the time and the energy you have.
The analysis also, of course, it starts being a bit different, just like the website, because you
will start to play with HTML. So it starts to be different. It's a new area. And I think
starting with package descriptions avoids any difficulty from a technical point of view.
Then poll files, it starts making you in front of the difficulty of the process, but, well,
okay, the process is done. And to finish, you come to HTML pages where it may seem for some
people somewhat difficult, because, well, you have to address tags and many things that you
have on an HTML page. So it may be somewhat difficult. And, however, it's important because
on the website, we have the security analysis, we have the publicity, we have all the platform for
the Debian project leader. So it may become important. And for any of these steps, you can,
of course, take the time, for example, to take three years to package descriptions and then wait
still three years for main pages, et cetera, according to your rhythm and your energy. And
especially, you can do what you want, review or translating. Generally, when arriving,
we suggest to review, to understand the conventions, to understand the things and to not
to take some time in your life. Then if you want to contribute to translating directly,
it's a good idea. What I mean here is that we can do really at the, well, with the ways,
with minimum ways and minimum installations and a minimum understanding things and especially on
the progressive ways. Also, you can track in translations. So you subscribe to the mailing
list and you have a look at translations and you follow what happens in matter of review
and in matter of translating new if you consider that it's simple or short enough to make you
spend the time to do it. So review and translating as the two steps, the two steps you can do at
any time in the process and in your way on Debian. So to conclude, I would say that it's not an
automated process because we don't have the capability to do that. And I think the project
is too complex today to do that efficiently. And it would imply some engineering to do things
properly. But we have today some way, I think, and it's what I try to suggest on the Wiki pages
about translation and how to contribute and to start contributing and not being discouraging,
discouraged, I could have been during some years. There is a way from the most obvious,
technically speaking, to less obvious with a contact with the community which is progressive.
And you discover how things work, the conventions, of course. The team discovers also if you are
ready to respect how the team works because we had some contributors which where we've
used it was complicated because they decided to do things like he wanted. Yes, but there is a team,
a history, so you can't do things as you want. Even if you're right, take the time and respect
what other people do. And also, it's important to say that on the mailing list, also, if you start
contributing via the mailing list, you have the chance to get your native language because
in the French mailing list, but also in Italian, in Spanish, or any language, you have for the
translation teams, of course, people speaking your native language. So, for example, now,
how to translate this English term in the language, it may be useful. And, for example,
in the package description, we also have a glossary to help people to know, okay, this English word
which has a strange translation, should I translate, or if I shouldn't translate, what should I do
with that? And if I should translate, what kind of word is used usually? And once you do that,
you can learn. And also, without any complicated tools or with no difficulties,
you can start translating. And so, you can become a deviant translator. Thanks.
Oops.
If you have some feedback or some questions.
For me, I can answer a feedback, a global feedback, a kind of policy feedback because
I have seen that maybe there is a fragmentation in different distributions in Linux, and some
have an advantage, and also not for this website. And so, because I never found a distribution
that convinced me perfectly. For instance, for me, you have problems with vision, but for me,
I have little problems with vision agronomy. And so, I should appreciate the scrolling bar
with a great enlarge, not a line to be picked up to adjust and sort of like that.
I have some problems like that. It makes Linux, they have a good scrolling bar,
but also problems. So, it's a kind, I'd like to wish more cooperation
with Linux, there was a problem of system day also, something like that. But I think it's
important for Linux community in general to have a better cooperation with different projects.
I think that the importance is free software, even if what you say is right, I'm okay with that.
But according to my understanding of things and about translation, it's right also,
is that the user finds a way for himself. I mean, that's, okay, Debian has his way of work,
human too has his way of work, and any project has his way of work according to the history,
according to what it needs to be done, et cetera. Well, the thing is how to enable a user to find
among all the existing ways a way for him. And I think it's right for any new users,
that's actually what you're saying, but also it's right for new contributors, because contributing
may work according to some rules, some community interactions, some tools, of course. So, it's
not a kind of what is better, what is not better, it's only a kind of is it sweet for you, actually.
And in the community, the benefit is that you have this diversity, which enables you to decide
what is good for you and what is good for your way of doing things. So, it's a good thing.
But yes, there are a lot of ways, and to find the way good for you is not easy.
I think the Delian community has something very good on which we should all learn to do is you
have a very good translation workflow, and I think this is something valuable, and this is the reason
why you are able to continue doing some e-mail translation still, even if the world is using
much different workflow, and I think that your bigger value is this. And my question would be,
what are the limitations that you see in the existing translation platform,
in terms of accessibility for you who are blind, but also in terms of way to collaborate as a team,
because I did a push for web late in many places, it helps a lot, but it doesn't create any miracle.
The community needs to find a way to define the workflow, the way to collaborate together,
and this is something that the rest of the open source community can learn from the Delian community.
Your tools are a little bit play-stricken, but you are in a way of working, are very clear,
and easy to understand, and I would be interesting to have your feedback on the translation
platform in terms of accessibility, and what are lacking to have a proper collaboration as a team
in what you have today. Thanks, because you sum up what I want to show here. What you say
is exactly what I think and I want to show, but I know, and I'm aware from some feedbacks I can
have, and because I know there is a low stream of new, a low flow of new contributors, that maybe,
and I say maybe because I'm not sure myself about that, because for me it, indeed, what
the tools we are using now are perfect because they are accessible, because they work, and because
they enable to have a record and to have a team collaboration, so for me these tools are really
perfect, but in the new generation of new contributors, I know that indeed there are some
more friendly interfaces, some more design, some ways to do a UI and UX, which is more
beautiful and more friendly, more attractive, more, also, or you have a less learning curve, so
you can come in the project, do something, up to leave, no problem, you don't have to learn during
some months, some things, et cetera, et cetera, so also the problem today is the new contributors
in the society is that people want, doesn't want less, want to get involved on the long term,
they want to come to try something, give it a try, up and to leave, because well, we have our
lives, we have our obligations, et cetera, and that's right in Debian, it's something more
difficult, because in libraries, for example, you can go, okay, you have an error or a mistake on
the string, you open the web later, up, you fix the string, up, and you leave away, and perfect,
well, in Debian, it's not possible, well, it's possible for the package description, because
it's a web interface, there is not a learning curve, it's very simple, but for people who don't
want to do the effort to learn, we don't want to do the effort of understanding deeply things,
well, it may be destructive. Is it a bad news? I don't know, I'm not sure, but the fact is that
the team is small, and the fact is that we have not few contributors, so I wonder if it's an
limitation, but for contributors who try their best to do that, I think these tools are, indeed,
are really, really perfect.
Yeah, just one more question for the neutral pinch.
So you've sort of approached us to create new translations, can you give some examples
how you, what you've tried and recipes to update existing translations, like the original text
changes, the English text changes, how to know about this, you notified the same translator as before,
did everybody jump in and change that?
Well, actually, for example, to take the deep core for the main pages, for example,
when there is an update, the translator has a warning, he knows that he has something which is
because the translator is considered as the last one who can do the changes or who should do the
changes. Once he has this warning, either via mail or because he has a look on the statistics page,
he says, okay, so I will do that. So he sends a mail with an address saying that, okay,
this page, this description, this profile, I will translate it. So there is a mail and the
community has the information, is notified that the person is going to translate. After it,
it will translate the profile or the file in it and then said, okay, now I finished, thanks to review
the translation. So there are some review, it's a process which can be on five days or 10 days
according to the number of mistakes which needs to be fixed, et cetera. And at the end, he says,
okay, last chance for change. So, okay, it's the last chance for you to review and to tell me if
there is a problem. And once that's done, when the mail arrives on the community team, if there is
not any reply, well, okay, the translator can either report a bug to say to the maintainer of
the package, okay, there is a new translation, it's updates. Please put it in your package or
you can do it itself, himself or herself, if the person has the permissions to access to the
git and the repository and to do the translation. So it's a manual, but of course there are some
scripts to do that. You don't have to do that manually, it's not a mandatory. But the process
is really, you have a follow-up of the situation via mail. Okay, thank you. Thanks.