Excellent. Thank you for the great talk. As someone whose first language wasn't English
and speaks other languages, I think localization and internationalization is a very important
topic that's near and dear to my heart, and especially when it comes to Emacs. I think
there's a lot that we could do better. So, yeah, thanks so much. Folks, if you have questions,
you can post them on IRC on the pad, and Jon-Karstof will answer them, and we will also open up
this big blue button for people who would like to join here and ask their questions
directly. Jon-Karstof, please take it away. Okay, thank you. I'm not seeing much activity
on IRC or the pad, so let me add a few things. First, that patch was really interesting in
terms of actually getting into the code and understanding how really can a beginner join
development, even if it's just a few lines. I mentioned in the first part of the presentation
that there was this small integration bug with Mac, and that's the thing that actually
got me started, and that was interesting because at the time I was trying to use Aquamax because
it looked simpler, and I thought, okay, if I need to fix that, rather than fixing it
in Aquamax, maybe I should just go to Emacs and fix it there. So, that was the first attempt
for me to actually contribute something serious, and it was really nice to – I mean, this
Emacs development list is really amazing. 99% of the discussion is just way above your
head, but sometimes you grasp something, and the more you grasp it, the more you understand
and the more you feel like you can actually do something, especially since – I mean,
as for all the free software development projects, most of them, I guess, it's really just do
it kind of thing. And if you try to do something, somebody's going to help you, and what I
really enjoy when being there is that the people are always very nice. Sometimes you
feel some tension when there are discussions about a specific topic, but it's – everybody
is really polite, I mean, 99% of the time. And what I like the most is all the people
are very strong opinionated, so they have a very good idea of what Emacs should be or
should not be, and so it gives you a very good idea of in what direction you should
go. So that experience – I mean, pretty much those 2017, 2018 years were until now
the peak of my Emacs activity. I've had to craddle with that because I was busy with
other things, but I'm really planning to go back to working on maybe not localization
because it's really – it's too big for me right now. And what I was told is that
it involved a bit of C programming and things like this, so I'm not really into that right
now. But I think eventually one day – I just turned 53, so I guess in a few years
from now when I have more time, I guess I'll just dive in and just work on those localization
issues and really to bring Emacs to a different world because I think it's – if we were
able to have – it's a big job. I mean, it's really – if you check the threads
on dev, check my name, you will see that I mostly post on translation or localization
issues at least at the time. And I did an estimate of the sheer volume of strings to
translate. For example, the manuals were about 2 million words. That's big. That's big.
But it's okay. I mean, it's not something that's impossible. And if you check the strings
– that was a really rough estimate. If you check the strings for Emacs proper, not even
talking about the packages and things, I think that would add probably like 500,000 words.
I mean, I have no idea, but my very rough estimate would be that. So it's not something
that's impossible to do. And we'd have to ensure that we have a good process for people
who review the strings and contribute new strings and things like this and also best
practices like what I tried to show in this video. And I was really not trying to be dismissive
about the people who worked on Package L because they did a wonderful job at actually helping
people like me access all those packages. So it's – I mean, the point of the video
is naturally to dismiss the code. But I was kind of scared because I was like, if they
write code like this for strings, then what about the rest of the code? Is it – so it
was kind of – I mean, something that I really can't evaluate. But I'm like – I mean,
those guys obviously are really smart and they're trying to make intelligent things
about how they want to factor their code, et cetera. But if they do that for strings,
which is quite simple actually – I mean, it's simple to mess up strings. So I was
like, what about the rest of the code? Is it that complex or that difficult to understand?
So that's kind of a put off for me. I'm like, I really don't want to try to envisage
that more because – plus it's not – it's really not my area at all. So anyway, that's
what I wanted to add. Yeah.
Awesome. Yeah, I think I pretty much agree with all of what you said.
Yeah, yeah, yeah. I have a question – I see a question on the pad. I use Emacs on
English, but my mother language is – no, no, no. Okay. So the answer is that Emacs
is not localized. And my understanding is that right now it's not localizable. And
those discussions took place about four or five years ago. So check on the dev list and
you'll see the state of the discussion because there is only a discussion at the moment.
What I did for package L, I think it was really just a one-time attempt at fixing one package.
And I did check the other – a number of other packages in core Emacs. And not a lot
of them had – I mean, as far as I checked. And I really did not check everything. But
basically what you have to do is check all the functions that impact strings. And some
are really not user-facing strings, so they're not really interesting for us. And actually,
that's really interesting to do that. So if you just take one list package, list code
and just go through the thing and just check all of print1, printc, message, format, concat
and stuff and just see how it goes.
So basically right now there is no infrastructure to localize the thing. There is no process
to extract the strings. And there is no way to actually import them back into the code.
So what we can do right now is really just what I did, make sure that it's eventually
possible one day. And as I just shown, it's really not such a big deal. If you're very
careful about understanding the way that the strings are handled, it's just a few rewrites
away. I mean, it's really not much. So there's – I mean, there's not a lot to be proud
about in my patch. But it was really fun. And I think it's a very good entry point
for people like us. I suppose – I mean, I suppose the first person question. I mean,
I don't know. Maybe I'm just – I should not suppose that. But people who really enjoy
working in Emacs and just sometimes would like to contribute something and are not programmers
or anything or maybe even programmers. I mean, I'm not excluding them. But that's really
a good way to just start doing something. And eventually from there, you can – I mean,
you just use a package that you like and that you think is important and just check the
strings and do things like this. And then eventually, you'll find other parts of the
code that you want to improve or add functions. So yeah, actually, the patch that I did, this
patch is actually in the process of the thing that I started with Equimax. So I did one
little thing regarding those that were not fully integrated in macOS. And then I did
something about a small function. I think I added the possibility to add an option.
I did documentation improvement as well. So really just little things. And then the deeper
you dive, the more interesting it gets. And then you find something that you really want
to do. So just use that entry point as a way to have fun in Emacs.
Well, so I mentioned Regex on strings. Well, it's not really a red flag for localization.
But the way it's used, I mean, I guess there are ways to properly use it. But I think really
the basically using that means that you're making assumptions on the way language is
structured. And I did exactly the same mistake on a different project that I'm working on.
Actually, I'm in charge of rewriting a manual. And we were using Docbook. And I just thought
it would be smart to have automated links to parts of the chapters, et cetera. And the
thing is that depending on the language, you've got different ways to introduce chapters.
So I should know that. I should know that. You should not automatically insert strings
in code because it's going to produce something that can't be handled by the translator. So
basically Regex on strings is something that probably you might use. But if you see, I
mean, you can see the way it was used in the original code. So if you see something like
that, I mean, just don't run and just fix the thing because there is no way these can
be localized, I mean, extracted properly and then localized. And that's the reason too
why numbers are a big problem because, for example, in English but in French too, we
have only singular forms and plural forms. But some languages have zero forms. Some languages
have two forms like pair forms. Some languages don't have a different form for anything.
For example, I live in Japan. I work in Japanese. And in Japanese, you don't have a form. You
don't have different inflections for words based on their number. So saying one whatever
or two whatevers or an infinity of whatevers or even zero whatever, it's just the same
form. So making assumption on the number of things and the way it's expressed in the language
is usually, and that's something that we already know in free software. I mean, if you check
the getex library, they've got everything sorted out. And that's something that was
created in the 90s at Sun Microsystem. And then it was freed, et cetera. But when you
see the work that it did at the time, you would kind of expect that people understand
that. But no. And that's OK because developers develop and localizers localize. So we kind
of split. But everything has been done already. So we just have to be aware of what's being
done. And we have to be aware of the rules. And I think of one very good set of rules
that's been online for a while. It's the Worldwide Consortium. They have a really good internationalization
page where everything is pretty much black on white on paper, on the web at least. And
if you read that, you can see exactly what should be done for localization, what should
not be done, what should be avoided at all costs, et cetera, et cetera.
So there are plenty of references here and there. And in terms of software localization,
it's the same. If you check the getex page, you should be able to get an idea of what
should be good. So is my project to localize all of Emacs? I wish it were. Eventually I'll
be rich. Hopefully. I don't know. I'm working on that. It's not working well. But the day
I can take just one year off totally and focus on that, I think that's something I would
love to work on and just get up to speed with the process of programming all the things,
checking all the things, and organizing the infrastructure. But seriously, I don't think
that will ever happen because I'm a poor translator. And I still have, what, like 20 years to go
before I can't work anymore. And we don't have savings or anything with the corona shit.
So I don't think that's ever going to happen. But I would love to help. And yes, yes. How
deep would useful localization go? Because the core of Emacs are duck strings and localization.
Yes, yes, yes. I mean, all those discussions have been made. I mean, no conclusion reached.
But we have addressed those things on the discussions. And so just, I mean, it's really
pretentious to say, check my name on the Emacs table list because I've talked about that.
It's really pretentious. But that's not what I'm saying. I mean, there has been a lot of
discussion on the development list. So if you check for localization, translation, stuff
like that, you'll see keywords, and you'll see the discussion. And people are aware of
the issues. So I mean, we just need to have a framework for that.
Thank you. Just to quickly chime in to say, I think we have about two more minutes of
on stream Q&A. And then you're welcome to either stay here, Jean-Christophe, or continue
taking questions on the pad on IRC.
I think, well, I got to go to work. So I need to get ready. But I think, unless we have
something on IRC, I think we're good. If you find something else that I've not addressed,
I'm good. Otherwise, yes, yes, yeah, we need to take all the C code. But I mean, you can
decide the level down to which you want to work. So you can go all the way to the C code.
But actually, the C code is actually easier to extract because there is all these get
text things that works on the C code already. So the issue is pretty much the Emacs Lisp
code, as far as I can understand. So that would be the process that we need to address.
Doc strings, indeed. But then the doc strings and the manual, they are very close. And actually,
yeah, my estimate of the 500,000 word, I think it was based on doc strings. So yeah, we need
to take all that. And that's an ongoing project that's not going to go away anyway. So we'll
be here 10 years from now, I'm sure.
OK, cool. And yeah, I think that's about all the time that we have on the stream. I guess
if folks have further questions, they could maybe reach out to you later on IRC or via
email.
And I'll be back on the development list shortly, maybe six months from now. So yeah, I can
take it from there.
Sounds great.
Thank you very much.
Yeah, thanks again for your great talk. Cheers.
Cheers.
OK, bye.