Thank you everyone, hi, I don't know if the microphone is, yeah, it seems to be working.
First of all, thank you for coming to our talk.
I hope we can get you excited about the work that we've been doing.
Ujbo and he's emily, eloquently introduced us.
And here's me trying to make something out of the first draft of the methods format to
spec.
It's been a while since we started work on this.
So I'm from New Delhi in India and I live in Akorunia, it's a fun city.
I love open source software, the web platform, it has taught me everything that I know.
And I hope that we can localize it to serve more people.
I also like badly designed video games and other things.
And I work at Egalya.
Hi, I'm Emily.
And I'm working on localization at Mozilla.
And as far as I know, I am the only person to work on localization and localization.
These are the robotic underwater floats that my dissertation work is based on.
They have absolutely nothing to do with today's talk.
I just like to be proud of the fact that I work on both localization and localization.
So one challenge that I like, the many challenges with localization these days.
And the first part of this is about presenting some of those that we hope to be able to be solved or made more solvable with message format too.
Then we're going to go on to talking about what is actually message format too.
What does it look like?
And then we're going to continue with some of the next steps of what can be done here.
So a big challenge really of where we are today is that localization is very much siloed.
These are very old silos, but you get the point, I hope.
Where you end up picking a solution for localization mostly often based on developing needs,
develop a desires and develop a presumptuous about how translators and translation works.
And then you kind of just go with it because siloes can be old or they can be newer,
but they're still siloes that we are mostly living in.
And this becomes difficult to move from one solution to a different solution.
You kind of stuck with it and the features of the localization systems that you end up with are kind of incidental.
And they don't solve all the problems that.
No, no, it was my question.
They don't solve all the problems that we actually have.
And many of those are actually honestly hard problems.
I could not think of a good image to go for.
Infection is for those of you not so deep into localization and internationalization.
Infection is effectively needing when you have a message to transform some of the words depending on other words in the message.
This doesn't happen so much in English.
For example, finish.
Finish does like.
We do suffixes.
Our suffixes of suffixes and those can also have suffixes that they can go on.
And then you can also of course change the stem based on the any gets a bit complicated.
In English, too, you have differences between A and Anne.
So is it A historical account or Anne historical account for instance?
So there's no not even a strict rule based solution for how this works.
And these sorts of problems are difficult to solve.
Message format is hopefully providing some of the better solutions here.
Another dimension in which message format is hopefully providing a better solution.
The better solution is when we have messages that you need to localize but they depend on not just one thing like the plural category of whether you have one message or three messages.
But also when you need to take into account grammatical gender or other aspects at the same time.
And you end up with the sort of either a tree structure or a matrix structure of all of these choices of what it is that you're actually localizing and how this works in different languages.
And the dimensions that you might need for your source language are not necessarily at all the dimensions you need for your target language and it gets complicated.
So we've been trying to solve this.
And the way we've been working on a solution is through standardization through finding and determining a good new standard for localization that we can build a solution or solutions on top of.
We're calling that message format too.
This work has been ongoing in the Unicode to Sultium under the CLDR.
Oh, this is a lot of acronyms here. I've got a skip for actively for about the last five years.
But for example, a lot of this work, the impetus for the current work came from the JavaScript side of things where we want something like in the JavaScript input message format to exist.
And the current proposal for what the Intel message format API looks like looks an awful lot like the proposal we have for it in 2013 when we decided we weren't quite ready to do this yet.
So even at the rate of standards, this is slow, but you know, we're getting there.
And with message format, too, we're hoping to get the final candidate out within literally a few months from now.
So we're working on it.
But what is this message format, too, that you know, is going to solve all the problems of localization in the world.
And that, as well, you might take the lead.
So having been done with nuance and all of that, let's go into the dirty details and talk about how not only the syntax looks, but how message format essentially approaches these complex problems that we talked about in localization and you know, give the most ergonomic tools to developers and translators a life.
So here's a very simple message. It just says hello fast and this is how it looks in sort of the energy data model that we have.
And if you've done localization before, you might notice that this is like maybe 90% of what you do ever, right, like every single static string on your interface is basically a simple message.
So this doesn't need to be more complex than this and we try to keep it as simple as we could by not having any syntax for this.
But once you start going through some of the more complex things by which I mean placeholders, you can have variables in your text.
So you could have some kind of simple dynamic text which replaces a variable or you can have markup in these.
So for instance, something like this, if you notice since we're in the inclusive web room, I think markup means something specific to you.
But in, you know, something that has at least the aspirations of message format too, we cannot make very strong assumptions about markup.
So the markup has been made to be as generally applicable as possible, but there's certainly some patterns that you can see.
But yeah, these markup elements can be either an opening element, a closing element or some sort of standard loan element that doesn't need to be closed.
Next we can have more complex expressions, so we already saw that one earlier just simple variable replacement, but you can have more interesting things in your expressions.
So here you can see that we're calling a function, it's a number of function with a style.
And since that style is currency, we're supplying the currency. So it's going to format it keeping all of these things in mind.
These function calls are pretty relevant to our work.
Basically, we hope to provide people the most common interpretations that they might need as sort of building blocks for more complex applications.
And we also give them the ability to come with their own functions, so they can customize these functions or build entirely new functions.
But yeah, they form sort of the building blocks of these various operations that you can do and express things in the mesh format syntax and sort of a combination of all of these different things different place holders, maybe some markup elements forms what we call a pattern.
So anything like this sort of relatively simple message is a pattern and it's sort of a combination of various strings, some expressions maybe and some markup elements.
And the most important thing about patterns is that at the end of the day every single message in message format is the result of formatting a pattern.
You can either be a simple pattern like this or it can be one of many patterns. What do I mean by that is you can have matters. So here we have a variable call come.
Because this variable is being supplied by whatever workflow you have and what you can do is have a match statement with this.
In this case, since we are using number, it defaults to doing plural selection, but there's various different things you can do with that.
I mean, you can do simple string matching or you could do things like ordinal matching all of these different rules that exist in a language.
You could sort of build different patterns for each of the cases that you want to handle and then you can write a message using a matcher so that it finds out which case applies to your message and formats that pattern.
So as you can see, we can have different variants and each of these variants come together as a select message where the final result is one of the different variants.
So, okay, well over to you.
So one question to ask here, what comes next?
After these initial steps, we have a syntax here. You saw some of that. You're not expected to remember all of it, but just we've done a lot of work here and we hope that it is a sufficiently good syntax that is going to get adoption, get used and get to get to be.
Because ultimately what we have now is the behavior of a single message, but if you have a single message that is localized, often you have not one but a whole pile of messages or possibly relating to each other that need to to be somehow defined together.
And for this work, we are kind of bootstrapping and getting onwards with a message resource specification.
That is going to define how specifically a message format two message is best placed together with others in a file or otherwise.
The message format two can be embedded in pretty much everywhere in any format that currently allows for abandon messages in different formats, but it's got properties like being naturally multi line in places that make it not sit in quite so well.
And other needs that we honestly don't have the time to get into, but it's also got we've identified a a lack in that the metadata about a message is not very well defined in the general case.
There are some specific instances where there's decent definitions of what is the context for a message coming from a developer or otherwise providing information for translators.
But for this we need to define a better system as a part of the message resource definition work.
And to do that we have been building these tools and are providing tools that hopefully are going to be used to pull things together, but we're not providing really a ready solution here really we're providing building blocks.
For for you to put the solutions together where we're not providing a monolith that does everything that you need we're doing kind of improvements on the angle.
He's very eager.
To do also we didn't practice this bit as well as we should have.
So putting messages together is challenging sometimes and part of that is because we think messages are complicated and complex, but they're actually not.
One thing that was was visible in the earlier parts where we was showing you the the syntax we also have this data model definition of what does the syntax mean.
And one benefit that might not be obvious and was not really an intended goal that we we had when we started but just did identify during the work of message from our two is that the data model we have for messages.
Is actually really good for representing all messages in all formats that currently exist like this so you can.
Parts effectively messages from any localization format used by anyone into this one data model and retain all of the information that you have there originally and then move on was from there.
So we kind of trying with that to also provide a building block for it systems to be put together to provide the solutions provide better monoliths better better silos because.
Ultimately we are not really here to build a provide you with with a solution for your silo we're going to make the internals of your silo work better because it's going to be able to.
Even if you currently don't use message format to in your messages because honestly none of you do yet you could parse your messages into a message format to data model and even have the runtime formatting use a message format to runtime to do so or do all sorts of other operations for which.
We are building tools other people are are building tools and and we're looking to to kind of build a whole ecosystem here and.
One of the ultimate places where we're kind of hoping to go here is to be able to.
Bring message format to a message resources to be directly in HTML so that in HTML you could declaratively say that this file depends on these localization messages much like we have CSS defining these days and then within the HTML say that this item.
You use this message reference to to to localize to provide the content for for this bit and that that's kind of cool but this of course depends on a whole stack of standards which we have some of it really ready some of it less ready.
And another interesting direction that you know this is going to enable is consideration of what happens with.
Translation memory that is systems that tell you that this thing that you're you're localizing translating.
It's been localized before and this is how it was localized before so translators don't need to repeat the same work over and over again.
And with the one data model representing all messages from all formats it's entirely doable to to consider improvements on on matching messages not just in this format that you've done but what you have previously and also.
Improved how do you do matching when the message is multi variant it's got multiple one or multiple things it depends on and and built from there.
And we're nearly done with the first part of this which is the message format to syntax and and here's a very small call to action in that you still have this small window opportunity to tell us that we're been doing this all wrong.
Because the message format to spec is still under review this means that if you.
The first one there is the to the message format working group if you tell there that this thing is wrong and you should fix this thing or that thing we might be able to still take you into account will say we're not going to do it because you know.
The reason this and reason that because honestly we did not this for like five years and we've talked about many things.
But you still have.
A little bit of time before we finalize the spec to make sure that we take into account whatever we didn't take you into account or might not have taken into account.
And there's a lot of other work ongoing there's this slides a link to from the.
From the first presentation so you don't need to take a photo this but you can.
There's the.
I mentioned about inflection that we're not providing a ready solution for inflection for anything because that depends on a lot of data about the unique code consulting is booting up a working group.
And so on quite a bit of data shared by Apple in particular.
And a system for working with inflection but that of course requires a whole pile of data per language in order to make work so it's it's not a universal solution in all systems.
The message format info message format proposal is is proceeding in T.C. 39 for JavaScript.
That's another place where you might be interested to look at and voice your thoughts.
The message resource working group is hopefully going to get finally transferred to the unicode organization relatively soon.
But from there there's a JavaScript implementation of the message format to spec that is pretty much complete and there's a set of tools in Python that we've been working on for our localization needs specifically at Mozilla.
It doesn't do formatting but it does a lot of everything else you could imagine doing with resources.
That might be interesting.
Have we, are there any more things we have to point?
Oh yeah and then the ICU is going to the internationalization components for unicode provided by unicode is together with the release of the message format to spec going to provide format for that for the C++ and Java implementations and the ICU for X rust implementation upcoming as well.
But yeah that is that's it for us.
Thank you for your time and attention.