I'm Jonathan Clark, a developer from the Document Foundation, working on improving language
support in the labor office.
Language supports very important for our project and for the foundation.
Many languages are endangered, many are going extinct.
I think the saddest thing is when people are forced to use a different language because their
software doesn't work in the language they want to use.
As developers, I think we have a tremendous opportunity and responsibility to make sure
that our project supports everybody's languages.
So, what we've been doing is fixing bugs.
In the last year, labor office developers have fixed more than 100 bugs directly related
to language support.
So, 34 of them were very, very old.
Speak up.
If there's one takeaway from this talk, it's that if you tried using labor office while
ago and it didn't work well for you because of your language, because of how we support
it, please try a new version.
The situation might be much better now.
There are too many bug fixes to talk about, so I just wanted to focus on one bug that
can help to kind of motivate and explain some of the challenges behind retrofitting good
language support into a mature code base.
This is a very old bug in labor office that's been around since the very beginning.
When you change the color of text inside an English word, the spacing of the letters gets
a little bit weird.
They kind of hide to see, so I blew it up and overlaid the two over there.
Now, this bug set on the back burner for a really long time, because it's kind of hard
to understand why it's important.
It seems like a very minor difference in text, and you always just tell a user not to do
this.
But it turns out that labor office actually does this automatically sometimes, for instance,
when you're using a track changes feature.
So we can't just tell you just not to do it, because we do it.
Why does this happen?
It's due to a very common assumption made by software developers, especially developers
who are most used to the Latin script.
We kind of tend to view computers as high-concept typewriters that just arrange letters from
left to right across the screen.
And so if that's what you believe about text, it leads you to an obvious abstraction.
Your graphics library, your graphics code, is responsible for atomically rendering text, pieces
of text, in a particular style using a particular font.
The application code is responsible for chopping text up into regions of interest, into stretches
of text that share the same style, whatever you have.
And this is what this ends up looking like.
So we saw where there are a virtual pen at a particular position on screen.
We tell our graphics library to draw a string in this case T, the first letter.
We advance our pen to the right by the width of the text that we drew.
Set the color, draw the rest of the text.
In this case another complete string, and advance the pen again.
So now we're ready to draw whatever text comes after this.
The problem is is that that's not the way that text works.
This turns out to be a very bad assumption.
In an English, we use lots of special font features to adjust the positions of characters
on a screen to make the text look more attractive.
So in software, this is something we call an architecture bug.
It's an assumption or a design decision made very early in the project that turns out
to be incorrect.
When you have an architecture bug, it's very difficult, very expensive to fix.
And in this case, fortunately for English text, it's only a minor irritation.
You can still understand the text.
It just looks a little bit funny.
But in software, we have this category of languages called CTL languages.
Stents for complex text layout.
The dictionary definition is writing systems where the shapes of the characters, the appearance
of the character, changes depending on the context in which the character appears.
CTL languages are sadly very often neglected by software projects.
Treated as an afterthought, but the group includes a number of heavy hitters.
But your project doesn't consider the needs of CTL languages.
You're giving up billions of potential users.
So the canonical example of a CTL language is Arabic script.
In Arabic, letters can change shape pretty dramatically depending on where they appear
in a word.
In this case, you can see here this is the isolated form.
And that's one of the pairs of the start of a word in the middle or at the end.
But this isn't an unusual phenomenon.
Even if you're only familiar with European languages, see this example of English cursive.
The shape of the letter E changes significantly depending on whether it's connected higher
or low.
If you try to render the other E in a different word, it would look pretty odd.
I might even confuse it for space in the middle of a word.
So the algorithm that I described previously really doesn't handle CTL languages well.
I can't read to mill, but those don't look very similar to me.
So the definition I gave before is kind of vague.
It's languages that are heavily affected by context.
I think an alternate definition might be a CTL language is one where when you try to use
the algorithm that we're talking about, it fails to substantially preserve meaning.
Just to make it clear, Librar office isn't alone in making this assumption.
It's very, very common.
May I have a time?
You have two minutes.
Two minutes, okay.
Many other software projects make the same assumption, including some very popular operating systems
and made by very big companies.
Anyway, two expensive to rewrite all of our application code to suit to fix this bug.
So instead, what we can do is just pass more information when we're figuring out what characters
to render this case once again, start at the origin.
This time, we're going to draw the entire text and just drop the characters that aren't included in this
section of the text.
Now we repeat the algorithm.
At the end, we've successfully laid out the text correctly.
Our approach isn't perfect.
It can't handle cases where characters actually rearranged in words, which is something I can
happen in CTL languages, but our results are much closer to what someone would expect when they're
using these languages.
And all this is to say that if you're writing a new software project today, it's very helpful to keep
these languages in mind because it's very difficult to reverse course once you've written a lot of application code.