WEBVTT captioned by brandelune and bhavin192
NOTE Introduction
00:00.000 --> 00:00:05.400
Hello everyone, I am Jean-Christophe Helary,
00:00:05.400 --> 00:00:09.680
I live in Japan, and I'm a translator.
00:09.680 --> 00:00:12.633
Here is my second presentation on this very
00:00:12.633 --> 00:00:15.300
prestigious stage that is the Emacs conference.
00:00:15.300 --> 00:00:18.367
Following my "Let's Translate the 2 million words
00:00:18.367 --> 00:00:21.767
in the Emacs manual" in 2021, my topic this year,
00:00:21.767 --> 00:00:25.167
always related to translation, is
00:00:25.167 --> 00:00:28.400
pre-localizing Emacs or much less pretentiously,
00:00:28.400 --> 00:00:31.933
"Just make sure that your strings don't mix up plurals".
NOTE Usage of package.el
00:00:31.933 --> 00:00:36.133
So, for some reason I resumed Emacs use
00:00:36.133 --> 00:00:39.940
around 2016, and as I was rediscovering the thing
00:00:39.940 --> 00:00:42.800
I found really old outline-mode files here
00:00:42.800 --> 00:00:44.033
and there on my machine.
00:00:44.033 --> 00:00:45.140
And I started to experiment
00:00:45.140 --> 00:00:47.167
again and write again with Emacs.
00:00:47.167 --> 00:00:48.564
I think that at the time,
00:00:48.564 --> 00:00:50.433
I was coming from Aquamacs and because of
00:00:50.433 --> 00:00:53.400
an integration bug with macOS, I decided
00:00:53.400 --> 00:00:55.440
to check what was going on in the code.
00:55.440 --> 00:00:59.040
That was my first official contribution.
NOTE The bug in strings
00:59.040 --> 00:01:02.233
So as I was happily installing and uninstalling
00:01:02.233 --> 00:01:05.267
things, I noticed something weird one day.
00:01:05.267 --> 00:01:09.080
Let me enlarge that picture.
01:09.080 --> 00:01:12.400
See? And even if I were not a translator,
00:01:12.400 --> 00:01:14.960
I would not like that string, and obviously
01:14.960 --> 00:01:16.833
the same bug bites you when the string
00:01:16.833 --> 00:01:20.520
tells you to erase the package.
01:20.520 --> 00:01:26.720
Boom, so we agree that we have a problem here.
NOTE Natural language engineering
01:26.720 --> 00:01:29.067
So, I started to do some spelunking into the code,
00:01:29.067 --> 00:01:31.067
and at least that was my feeling
00:01:31.067 --> 00:01:33.100
because I really am not a programmer
00:01:33.100 --> 00:01:37.240
by any stretch of the imagination.
01:37.240 --> 00:01:39.467
And what I found was an amazing piece of
00:01:39.467 --> 00:01:41.840
natural language engineering that was mixing code
01:41.840 --> 00:01:44.267
with English suffixes and all that,
00:01:44.267 --> 00:01:46.267
and I could see that the people who had
00:01:46.267 --> 00:01:47.767
written that code were pretty smart,
00:01:47.767 --> 00:01:49.533
but had missed a number of edge cases
00:01:49.533 --> 00:01:51.280
that produced the above bugs.
01:51.280 --> 00:01:53.500
That was my first experience with
00:01:53.500 --> 00:01:55.033
all the message related functions,
00:01:55.033 --> 00:01:58.360
"format", "concat", "message", etc.
01:58.360 --> 00:02:00.433
But even with my beginner's eyes I could see that
00:02:00.433 --> 00:02:03.040
something was off because when you want
02:03.040 --> 00:02:06.000
to produce natural language strings you never ever
00:02:06.000 --> 00:02:08.600
should use "replace-regex-in-string" to
02:08.600 --> 00:02:11.067
add an "ing" or an "ed" suffix
00:02:11.067 --> 00:02:12.980
to change the mode of a sentence.
02:12.980 --> 00:02:16.840
But that's what I was seeing was happening.
NOTE More than a missed plural
02:16.840 --> 00:02:20.333
So, what we had to deal with here
00:02:20.333 --> 00:02:22.220
was way more than just a missed plural.
02:22.220 --> 00:02:24.000
It was an attempt at engineering all
00:02:24.000 --> 00:02:26.400
the message strings destined to the user
00:02:26.400 --> 00:02:28.567
with the smart code that was making assumptions
00:02:28.567 --> 00:02:30.067
on the structure of words,
00:02:30.067 --> 00:02:33.220
and in the localization world that's a big no-no.
02:33.220 --> 00:02:36.667
I'm a translator, and such UI strings issues
00:02:36.667 --> 00:02:38.433
have been sorted out decades ago.
00:02:38.433 --> 00:02:41.320
So I was a bit shocked.
NOTE The final patch
02:41.320 --> 00:02:43.533
The final patch took me about a year to write,
00:02:43.533 --> 00:02:45.380
because I'm slow, because I needed to verify
02:45.380 --> 00:02:47.167
and understand a lot, because there are
00:02:47.167 --> 00:02:49.100
plenty of rules and plenty of people who are
00:02:49.100 --> 00:02:51.433
explaining you very nicely what the rules are,
00:02:51.433 --> 00:02:53.733
because I have kids, and because the
00:02:53.733 --> 00:02:55.600
Emacs development list is such a cool place to be
00:02:55.600 --> 00:02:58.560
that you often forget why you're there sometimes.
02:58.560 --> 00:03:01.800
Anyway, for people who can't click on a video,
00:03:01.800 --> 00:03:03.640
and I can't either, here are the relevant
03:03.640 --> 00:03:05.840
parts with some short comments.
03:05.840 --> 00:03:07.800
I'll be talking with localization in mind,
00:03:07.800 --> 00:03:09.640
knowing full well that Emacs localization
03:09.640 --> 00:03:12.800
is not on the map at the moment.
03:12.800 --> 00:03:14.167
So first, there is this thing
00:03:14.167 --> 00:03:15.520
about "format" and "concat".
03:15.520 --> 00:03:17.800
And if I remember correctly,
00:03:17.800 --> 00:03:20.300
"format" is better for user-facing things,
00:03:20.300 --> 00:03:25.160
and "concat" is better for internal things.
03:25.160 --> 00:03:26.800
Here, there are two things.
03:26.800 --> 00:03:28.800
First, a rule that we have when we prepare
00:03:28.800 --> 00:03:30.700
strings that need to be localized is
00:03:30.700 --> 00:03:33.333
never ever make assumptions on the way
00:03:33.333 --> 00:03:35.780
numbers are expressed in the language.
03:35.780 --> 00:03:37.067
Here, the assumption is that
00:03:37.067 --> 00:03:40.000
we have either a singular or plural form,
00:03:40.000 --> 00:03:42.040
and that's not always the case.
03:42.040 --> 00:03:44.067
That usually means that you should externalize
00:03:44.067 --> 00:03:48.280
numbers and find a generic way to express them.
03:48.280 --> 00:03:50.833
So it makes for slightly less natural
00:03:50.833 --> 00:03:54.400
language strings, but it's better anyway.
03:54.400 --> 00:03:56.667
Then we have that comma there that's trying
00:03:56.667 --> 00:03:58.167
to be externalized and that's weird,
00:03:58.167 --> 00:04:02.620
so I put it back into the sentence.
04:02.620 --> 00:04:04.967
Here we have another construct, or two rather,
00:04:04.967 --> 00:04:06.960
that really should not be used like this.
04:06.960 --> 00:04:10.033
It's "prin1" that uses quoting characters,
00:04:10.033 --> 00:04:12.480
just like "print", and "princ" that does not.
04:12.480 --> 00:04:15.400
And you see why they were combined together.
04:15.400 --> 00:04:17.133
And they were both trying to be really smart
00:04:17.133 --> 00:04:19.780
about which article to put in front of a vowel.
04:19.780 --> 00:04:20.960
And you just don't do that.
04:20.960 --> 00:04:25.000
You just keep things simple.
04:25.000 --> 00:04:26.633
Here again, the code is trying to be smart,
00:04:26.633 --> 00:04:28.480
but it's really not much more efficient than
04:28.480 --> 00:04:34.940
plainly stating what you want.
04:34.940 --> 00:04:36.500
And here again, we have "concat" things
00:04:36.500 --> 00:04:40.367
that we could just use to plainly state
00:04:40.367 --> 00:04:41.980
what we want to state.
04:41.980 --> 00:04:49.880
So, instead of "concat" I just put a "message".
04:49.880 --> 00:04:52.260
And here we have something that's very cute.
04:52.260 --> 00:04:54.540
It's a computerized plural.
04:54.540 --> 00:04:55.700
Here again, assuming that
00:04:55.700 --> 00:04:58.640
there are only plural or singular forms.
04:58.640 --> 00:05:00.867
But the end string is not that much more natural
00:05:00.867 --> 00:05:02.700
than the fix, the code is less efficient
00:05:02.700 --> 00:05:07.760
and is harder to understand.
05:07.760 --> 00:05:09.433
Here again, the code is trying to make
00:05:09.433 --> 00:05:13.520
smart things where it could be much simpler.
05:13.520 --> 00:05:14.667
That is the part where you get the
00:05:14.667 --> 00:05:19.480
number of packages and their names.
05:19.480 --> 00:05:22.067
Here the whole sentence with the semicolons
00:05:22.067 --> 00:05:26.333
and the question mark is split in parts,
00:05:26.333 --> 00:05:29.180
between which something will be inserted.
05:29.180 --> 00:05:34.240
That's really ugly and difficult to read.
05:34.240 --> 00:05:37.700
Here again, another "ing" waiting to be
00:05:37.700 --> 00:05:44.840
regex-inserted into the code.
05:44.840 --> 00:05:46.633
And here at last, we get to the point
00:05:46.633 --> 00:05:48.760
where everything started.
05:48.760 --> 00:05:50.833
And you can see that unlike in the other spots,
00:05:50.833 --> 00:05:52.400
there is no possibility for the expression
05:52.400 --> 00:05:54.680
to be singular.
05:54.680 --> 00:05:57.600
So, I guess that if it hadn't been for that bug,
00:05:57.600 --> 00:05:59.320
I would not have found the other items,
05:59.320 --> 00:06:01.033
and we would be left with code that works,
00:06:01.033 --> 00:06:02.033
of course, but that is
00:06:02.033 --> 00:06:06.020
harder to understand, and maintain.
06:06.020 --> 00:06:08.333
Last but not least, a last version of
00:06:08.333 --> 00:06:10.920
"just plainly state what you mean to state".
06:10.920 --> 00:06:14.880
Keep it simple.
NOTE "What did I learn, and how did I learn it?"
06:14.880 --> 00:06:19.267
So first, we have this wonderful CONTRIBUTE file
00:06:19.267 --> 00:06:21.267
that is very explicit about
00:06:21.267 --> 00:06:23.520
how we must proceed when contributing code.
06:23.520 --> 00:06:25.233
So, that's really the first place
00:06:25.233 --> 00:06:27.760
that we should all read.
06:27.760 --> 00:06:29.333
The README file is pretty cool too,
00:06:29.333 --> 00:06:30.967
especially at the beginning of the process,
00:06:30.967 --> 00:06:31.867
when you're not sure whether
00:06:31.867 --> 00:06:36.240
you want to fix that bug or just report it.
NOTE Useful packages
06:36.240 --> 00:06:37.920
And then we've got packages.
06:37.920 --> 00:06:39.900
We've got a number of packages that are really
00:06:39.900 --> 00:06:42.600
helpful when it comes to reading
00:06:42.600 --> 00:06:45.880
the information and the manuals.
06:45.880 --> 00:06:48.000
I'm mentioning three of them here,
00:06:48.000 --> 00:06:53.720
and I think they are the most important for us.
NOTE Package: helpful
06:53.720 --> 00:06:55.600
So "helpful" is on the right,
00:06:55.600 --> 00:06:58.667
and it's overflowing the window with
00:06:58.667 --> 00:07:01.900
all the contextualized information it provides,
00:07:01.900 --> 00:07:05.280
and the standard "help" is on the left.
07:05.280 --> 00:07:07.933
I mean, really there are like two or three
00:07:07.933 --> 00:07:11.567
screen-full of information in the "helpful" output,
00:07:11.567 --> 00:07:13.233
so you really only see a part,
00:07:13.233 --> 00:07:16.320
but I guess if you use it, you know what I'm saying.
07:16.320 --> 00:07:18.867
What I like the most here is the "view in manual"
00:07:18.867 --> 00:07:21.800
part, where you can actually click and even get
00:07:21.800 --> 00:07:23.667
more information that's sometimes
00:07:23.667 --> 00:07:28.400
easier to read and understand.
NOTE Package: inform
07:28.400 --> 00:07:33.640
And then you've got the "info" versus "inform" formats.
07:33.640 --> 00:07:34.567
When you're in the manual,
00:07:34.567 --> 00:07:37.140
"inform" makes a huge difference.
07:37.140 --> 00:07:39.367
You can see here that you've got colorized items,
00:07:39.367 --> 00:07:42.000
and also in the middle you've got that
07:42.000 --> 00:07:45.000
'read' part that's green and bold.
07:45.000 --> 00:07:49.333
In "info" it's not a specific object,
00:07:49.333 --> 00:07:52.200
it's just a string. In 'inform' it's actually
00:07:52.200 --> 00:07:53.800
a link that you can click,
00:07:53.800 --> 00:07:58.320
and actually go to that 'read' manual page.
NOTE Package: which-key
07:58.320 --> 00:08:01.300
Now, we've got "which-key".
08:01.300 --> 00:08:03.400
"which-key" is a savior for beginners too.
08:03.400 --> 00:08:04.867
Just wait half a second or something,
00:08:04.867 --> 00:08:06.500
and Emacs will show you all the keys
00:08:06.500 --> 00:08:08.433
that you can access from the prefix combination
00:08:08.433 --> 00:08:09.920
that you just typed.
08:09.920 --> 00:08:13.200
So, it's really helpful for discovering functions
00:08:13.200 --> 00:08:19.160
and learning new functions, getting used to them.
NOTE It all started with this message…
08:19.160 --> 00:08:21.500
And so that whole process started…,
00:08:21.500 --> 00:08:26.533
it was May 23, 2017,
00:08:26.533 --> 00:08:30.440
with that thread when I found the bug.
08:30.440 --> 00:08:32.800
I just bumped into an English/code bug
00:08:32.800 --> 00:08:36.920
this morning. In package.el, when one package
08:36.920 --> 00:08:39.033
is not needed anymore, the message is:
00:08:39.033 --> 00:08:41.300
"Package menu: Operation finished.
00:08:41.300 --> 00:08:44.880
1 packages are no longer needed", etc.
08:44.880 --> 00:08:49.633
So, I was asking whether we had best practices
00:08:49.633 --> 00:08:53.800
for using messages, and we had a whole thread
08:53.800 --> 00:08:57.867
about that. And while I was discussing on that
00:08:57.867 --> 00:09:01.240
thread, I started that new thread, which is:
09:01.240 --> 00:09:02.867
"package.el strings".
00:09:02.867 --> 00:09:09.900
The whole thing actually ended on June 27, 2018.
00:09:09.900 --> 00:09:15.400
So, a year after, with that message from Noam
00:09:15.400 --> 00:09:18.567
telling me that "Yes I can close the bug,"
00:09:18.567 --> 00:09:22.040
and that was it.
09:22.040 --> 00:09:24.000
So, it took about a year to finish that.
00:09:24.000 --> 00:09:28.133
What I did learn basically is that
00:09:28.133 --> 00:09:32.160
helping with Emacs is not that difficult.
09:32.160 --> 00:09:36.100
It takes time when you're not fluent with the code,
00:09:36.100 --> 00:09:37.100
but that's okay because the reference
09:37.100 --> 00:09:39.300
is excellent, and there are lots of people
00:09:39.300 --> 00:09:41.520
who are here to help.
NOTE Conclusion
09:41.520 --> 00:09:45.700
Basically, the solution to all our problems is
00:09:45.700 --> 00:09:47.733
"Keep It Simple and Straightforward".
00:09:47.733 --> 00:09:51.033
As you can see in that patch,
00:09:51.033 --> 00:09:53.233
even if it's a beginner's patch,
00:09:53.233 --> 00:09:57.733
what I did shows what can be done by Emacs Lisp
00:09:57.733 --> 00:09:59.533
beginners to help with "straightening" the strings
00:09:59.533 --> 00:10:02.267
to reduce the number of potential English bugs.
00:10:02.267 --> 00:10:04.533
And then to make Emacs strings easier
00:10:04.533 --> 00:10:07.233
to be handled by real localization processes one day.
00:10:07.233 --> 00:10:09.067
But it doesn't have to be about strings
00:10:09.067 --> 00:10:12.767
because strings can be an easy entry point to Emacs,
00:10:12.767 --> 00:10:16.720
but it can be any itch that you want to scratch.
10:16.720 --> 00:10:18.267
And my real conclusion is that
00:10:18.267 --> 00:10:22.160
Emacs is free software, and what that means is mostly
10:22.160 --> 00:10:24.067
that it allows you to do things that you would
00:10:24.067 --> 00:10:27.920
never have thought of being able to do before.
10:27.920 --> 00:10:32.000
That's really the biggest lesson to be learned here.
10:32.000 --> 00:10:33.400
So, I want to thank all the people
00:10:33.400 --> 00:10:37.920
who allowed this to be happening, allowed me to
10:37.920 --> 00:10:41.267
learn a bit and contribute a bit to that wonderful
00:10:41.267 --> 00:10:42.800
piece of software that Emacs is.
00:10:42.800 --> 00:10:44.533
And thank you everyone for listening,
00:10:44.533 --> 00:10:46.700
and hopefully I'll see you next year
00:10:46.700 --> 00:10:51.520
with a different translation related presentation.
10:51.520 --> 11:13.640
Thank you very much.
