[00:00.000 --> 00:11.560]  So, hello everyone, and thank you very much for resisting this late in the evening, and
[00:11.560 --> 00:16.400]  we have our last talk, and we have Emily Haro.
[00:16.400 --> 00:23.640]  Welcome to the localization system and tool chain management, and he's going to have
[00:23.640 --> 00:27.560]  a talk on the road to int-message format.
[00:27.560 --> 00:31.760]  Oh, the int-message format, I should have checked it.
[00:31.760 --> 00:32.760]  It's okay.
[00:32.760 --> 00:33.760]  Hi.
[00:33.760 --> 00:34.760]  Hi.
[00:34.760 --> 00:43.080]  So, the last talk by Mathias, if you were here, was a lot about where we are now, what
[00:43.080 --> 00:48.120]  we can provide now already in Pontoon and otherwise, how localization is now happening
[00:48.120 --> 00:49.280]  in Mozilla.
[00:49.280 --> 00:55.480]  What I'm going to be talking to you about is what's kind of coming up, what are some
[00:55.480 --> 01:01.520]  of the next things in localization that we're working on and that we think are really quite
[01:01.520 --> 01:03.020]  important.
[01:03.020 --> 01:12.400]  And so, yeah, I'm on the same team with Mathias and my staff, the software engineer, but I've
[01:12.400 --> 01:18.960]  been doing this sort of stuff kind of for fun, for ages, it feels like now, so it turns
[01:18.960 --> 01:23.680]  out that when you get really into localization in JavaScript in particular, there aren't
[01:23.680 --> 01:29.320]  too many other people who are that into it and then somehow you might end up hired by
[01:29.320 --> 01:32.480]  Mozilla to do the things you were doing for fun, for pay.
[01:32.480 --> 01:33.480]  So that's kind of nice.
[01:33.480 --> 01:38.880]  Hint, hint, you know, it's a good company.
[01:38.880 --> 01:44.280]  In addition to working just on code at Mozilla, I spend a lot of time in a bunch of different
[01:44.280 --> 01:50.000]  standards bodies working on the standards for localization in particular.
[01:50.000 --> 01:55.160]  And some of the work I'm presenting here is really the work that's going elsewhere
[01:55.160 --> 02:02.000]  than just at Mozilla because we want to have, we fundamentally want to make the world a
[02:02.000 --> 02:06.000]  better place, the internet a better place for everyone, not just Firefox users, but
[02:06.000 --> 02:11.880]  you know, everyone's internet isn't better if they use Firefox, but you know, you know,
[02:11.880 --> 02:15.720]  you're here so you might have heard this one before, but yeah.
[02:15.720 --> 02:21.320]  On localization, this is again covering a bit of what Matiasz was saying that quite
[02:21.320 --> 02:26.880]  often localization is one of those aspects of how do you really build an application
[02:26.880 --> 02:32.320]  or a site or anything that comes up way too late.
[02:32.320 --> 02:37.200]  You end up making some choices early on and then you end up needing to live with those
[02:37.200 --> 02:42.920]  choices later and they might not be the best stuff, best ones.
[02:42.920 --> 02:47.720]  And the need for localization comes after you've made the choices or you discover that
[02:47.720 --> 02:53.440]  hey, this thing, oh good grief, we need to support Arabic now, that'll be interesting.
[02:53.440 --> 03:00.400]  And a lot of, the sort of scope of localization is interesting because there isn't necessarily
[03:00.400 --> 03:07.760]  one right answer, so of course we're working on a new right answer and you know, there's
[03:07.760 --> 03:09.640]  an XKCD comic on that.
[03:09.640 --> 03:14.920]  I don't have it on these slides, don't worry, but you know the one I'm talking about.
[03:14.920 --> 03:18.400]  So things could definitely be better.
[03:18.400 --> 03:25.200]  So we're trying to make some of this improvements happen.
[03:25.200 --> 03:33.600]  It should be easier to localize content and there should be a common way of doing this
[03:33.600 --> 03:41.000]  so that the experience and use, the benefits that you get from using software and libraries
[03:41.000 --> 03:43.280]  in one place can map to elsewhere.
[03:43.280 --> 03:49.320]  Right now, there's a lot of differences in how localization ends up depending on the
[03:49.320 --> 03:56.520]  formats you use and the tool chains you use and all of this and that is not optimal.
[03:56.520 --> 04:03.440]  And fundamentally, a lot of actually when you start getting deep into it UI and UX design
[04:03.440 --> 04:09.600]  ends up being limited to some extent by the fact that most of localization work is working
[04:09.600 --> 04:18.800]  around strings rather than the complex structures like HTML allows us to represent and other
[04:18.800 --> 04:21.680]  aspects that make life more complicated.
[04:21.680 --> 04:23.960]  So we want to improve all of that.
[04:23.960 --> 04:28.200]  So let's start with this.
[04:28.200 --> 04:30.640]  This is nominally something simple.
[04:30.640 --> 04:35.360]  Hopefully most of you can read HTML to figure out that here we have this small little span
[04:35.360 --> 04:40.640]  that says that Brussels is the capital of Belgium, I've lived here, I know it's more
[04:40.640 --> 04:44.640]  complicated than that, let's just go on.
[04:44.640 --> 04:46.400]  And Brussels here happens to be a link.
[04:46.400 --> 04:48.960]  So how do we make this localizable?
[04:48.960 --> 04:55.720]  How do we, no, how do we actually localize this in a way that works really in the end
[04:55.720 --> 04:57.080]  for everyone?
[04:57.080 --> 05:02.760]  And one way that we're trying to sort of build towards is something a little bit like this
[05:02.760 --> 05:09.040]  that you could add an identifier to the element there where you say that this is the Brussels
[05:09.040 --> 05:13.120]  message that we're really dealing with and include in the HTML something like what we
[05:13.120 --> 05:18.280]  have for CSS now where you say that here's this resource that's attached, here's a link
[05:18.280 --> 05:24.040]  to a resource that's necessary for figuring out what's really the content of this page.
[05:24.040 --> 05:29.560]  And then separately you have a message here in Finnish because you know I can and I could
[05:29.560 --> 05:33.040]  not pick between French and Flemish and because it gets complicated.
[05:33.040 --> 05:39.840]  I've lived here, I know, Brussels and Belgium.
[05:39.840 --> 05:44.360]  And here the format that we're using, I'm going to get to that later, but there's a
[05:44.360 --> 05:50.720]  couple of interesting things here in particular that the fact that we're marking up the Brussels
[05:50.720 --> 05:56.960]  text there as the contents of the text of a link so that we'll be able to map that to
[05:56.960 --> 06:03.280]  the link, the AHRF that we have in the source document there in English.
[06:03.280 --> 06:08.920]  And because it's, you know, of course a little bit more complicated than this, it happens
[06:08.920 --> 06:10.120]  to be a link to Wikipedia.
[06:10.120 --> 06:16.400]  So in this particular case, but not usually at all, we could allow the translator to say
[06:16.400 --> 06:21.400]  that hang on, this link in Finnish should really go to the Finnish Wikipedia page on
[06:21.400 --> 06:25.120]  Brussels rather than the English one.
[06:25.120 --> 06:31.240]  And this is like, I can present to you, you can see the screen, you can kind of get what
[06:31.240 --> 06:35.840]  you're looking at here, but honestly getting this to a state where you can get a translator
[06:35.840 --> 06:41.760]  who's not a developer to see this and understand what they're supposed to do and not screw
[06:41.760 --> 06:47.560]  it up and provide useful things, useful content in all the languages, well, the languages
[06:47.560 --> 06:51.320]  that this translator is working on, it gets kind of hard.
[06:51.320 --> 06:55.240]  So we're trying to, you know, make that a thing.
[06:55.240 --> 07:01.360]  And the rest of this presentation is really going to answer these three questions that
[07:01.360 --> 07:05.400]  I kind of would have hoped some of you would be asking, but you're not.
[07:05.400 --> 07:08.600]  There are really questions in my head I wish you would be asking, you might have as well.
[07:08.600 --> 07:13.600]  But these are the questions of the theoretical guy in my head might be asking, what's the
[07:13.600 --> 07:18.280]  format of this thing that we just saw and is this really going to work like everywhere
[07:18.280 --> 07:23.760]  and how's this going to make my life better now or do I need to start using this whole
[07:23.760 --> 07:26.440]  new thing and that's going to be a pain.
[07:26.440 --> 07:28.240]  So I don't want to do that.
[07:28.240 --> 07:36.600]  To tackle the first one, the answer ultimately to all of that is to standardize everything.
[07:36.600 --> 07:41.800]  And the first thing we're going to talk about standardizing is the message there itself.
[07:41.800 --> 07:45.880]  And one particular thing that some of you might have noticed is that it had curly braces
[07:45.880 --> 07:53.040]  around the text there, around the Brussels on Helsinki, sorry, Brussels on Belgian Pääkkarpunki.
[07:53.040 --> 08:00.080]  Sorry, what's that?
[08:00.080 --> 08:04.920]  And this is because it turns out that when you're building a message formatting language
[08:04.920 --> 08:09.760]  like this, oh good grief all the corner cases.
[08:09.760 --> 08:15.640]  Oh good grief is it like hard, like proper hard because you're trying to write a formatting
[08:15.640 --> 08:22.160]  language that developers understand and then get the developers to write content in that
[08:22.160 --> 08:27.480]  language that translators understand without needing to have the developers necessarily
[08:27.480 --> 08:29.840]  understand how translators think.
[08:29.840 --> 08:34.120]  So you need to find an intermediate language for the communication to happen that explicitly
[08:34.120 --> 08:39.680]  limits and forces the communication to work in a way that works.
[08:39.680 --> 08:44.440]  And this is one of the reasons why some parts of this work have been in the active standards
[08:44.440 --> 08:46.560]  body for like three years so far.
[08:46.560 --> 08:55.920]  Yeah, one reason for those curly braces there is that quite often messages get complicated
[08:55.920 --> 09:02.280]  because you need to vary different parts of them depending on different variables.
[09:02.280 --> 09:10.400]  In English for instance it matters is it a he or a she or a day who might have you know
[09:10.400 --> 09:14.200]  done the action here of sent an invite to a party.
[09:14.200 --> 09:21.560]  So we need to have a language message format too which I'm presenting to you here to enable
[09:21.560 --> 09:24.320]  this sort of a communication.
[09:24.320 --> 09:29.080]  And of course it gets more complicated than this because you can have stuff like here
[09:29.080 --> 09:36.080]  we have a need to include something more in the message of the relative time like say
[09:36.080 --> 09:40.360]  three days ago that's included here.
[09:40.360 --> 09:46.920]  So the language needs to allow for internal variables for this message to be definable
[09:46.920 --> 09:52.400]  in a way that translators can kind of see what's going on and hopefully not touch it
[09:52.400 --> 09:56.320]  too much because hopefully they don't need to do that but still be able to do so if they
[09:56.320 --> 09:59.560]  really really need to.
[09:59.560 --> 10:07.560]  So this is about the space of what's possible in most current no in some of the current
[10:07.560 --> 10:09.920]  message formatting languages.
[10:09.920 --> 10:16.280]  At least project fluent which we maintain and work with and maybe one or two others.
[10:16.280 --> 10:23.000]  But when it gets really more complicated than that this is this gets on the edges of not
[10:23.000 --> 10:26.000]  really even supported anywhere.
[10:26.000 --> 10:30.960]  When you have here what we have are multiple different variables being defined and then
[10:30.960 --> 10:36.600]  the matching on which of these messages really the message we're building it depends on how
[10:36.600 --> 10:41.800]  many people as well as the gender of the host.
[10:41.800 --> 10:47.880]  So this isn't even a full listing of the whole set of possible when cases that could
[10:47.880 --> 10:54.160]  be selected here but this is all possible.
[10:54.160 --> 11:02.240]  Quite often happens when you really want to formulate UX experience that is approaching
[11:02.240 --> 11:08.520]  natural language and this is again referring to what I mentioned earlier a lot of this
[11:08.520 --> 11:16.160]  stuff just isn't is the choices that people are making now regarding message formatting
[11:16.160 --> 11:20.920]  how do they formulate it are driven by the limitations of the technologies that we have
[11:20.920 --> 11:22.400]  available for us.
[11:22.400 --> 11:29.200]  So UX itself is being driven in certain directions because message formatting is hard and you
[11:29.200 --> 11:35.320]  don't end up really having messages like this in your UI if you care about localization
[11:35.320 --> 11:41.200]  because whoever is filtering your messages before they go to the translators the localizers
[11:41.200 --> 11:44.200]  is going to tell you yeah no you can't do that they're not going to ever be able to
[11:44.200 --> 11:45.440]  work with it.
[11:45.440 --> 11:50.640]  So please fix and then you end up even maybe building the UI differently in order to accommodate
[11:50.640 --> 11:52.240]  these needs.
[11:52.240 --> 11:58.600]  With message format too which this is I kind of hope we can get beyond that have the possibility
[11:58.600 --> 12:07.680]  and the options of having even richer content in everything that we're working with.
[12:07.680 --> 12:14.400]  But the second question there was about is this really going to work everywhere and yes
[12:14.400 --> 12:21.240]  and we're doing that by trying to make much of the work happen at the lowest possible
[12:21.240 --> 12:27.000]  appropriate level for the work so a lot of this is happening in the Unicode consortium
[12:27.000 --> 12:32.400]  and then we've got work going on in TC39 for JavaScript.
[12:32.400 --> 12:41.640]  It's being added to the ICU libraries provided by Unicode as well and eventually we're hoping
[12:41.640 --> 12:50.240]  to get probably in what we do discussions ongoing about the structure of the HTML stuff
[12:50.240 --> 12:54.440]  that I was showing you earlier because that doesn't exist either yet.
[12:54.440 --> 13:02.040]  And one particular part of this I'm my background is as a JavaScript developer is that this
[13:02.040 --> 13:07.360]  is the first time we're really adding something to the JavaScript language itself at the level
[13:07.360 --> 13:12.880]  of like JSON.parse where you have this string representation of a thing that's not JavaScript
[13:12.880 --> 13:17.360]  and you get an object or a thing out of it.
[13:17.360 --> 13:21.280]  I think that's really cool but we're still working on it.
[13:21.280 --> 13:32.080]  And the part here that makes this extra interesting is that we're not just talking about a new
[13:32.080 --> 13:40.440]  syntax but effectively through the work we've been doing it's looking an awful lot like
[13:40.440 --> 13:46.160]  everything in every single message formatting language that currently exists and is in use
[13:46.160 --> 13:52.400]  somewhere that is, you know, that we can know about that is not like closed and proprietary
[13:52.400 --> 13:57.840]  is supported in the data model that we end up with for message format too.
[13:57.840 --> 14:03.400]  So for example to answer the earlier talks questions about how do you get support for
[14:03.400 --> 14:12.760]  something like Fluent into software like translate toolkit, one quite probable answer for the
[14:12.760 --> 14:18.520]  general case of this is that what you'll be able to do is take messages that you have
[14:18.520 --> 14:26.280]  in dot properties files, Fluent, GetText, ExLiv, pretty much anything and parse that
[14:26.280 --> 14:33.400]  into defined data model structure for message format too, then be able to work with that
[14:33.400 --> 14:41.160]  using tools, runtime, whatever and possibly from there get it out in a different format
[14:41.160 --> 14:44.880]  altogether that's then supported by other tooling.
[14:44.880 --> 14:50.760]  So it's a lot of this work is trying to figure out that hang on, messages aren't really
[14:50.760 --> 14:57.920]  all that complicated as data structures in the end or we can at least express the level
[14:57.920 --> 15:11.800]  of the complexity, so we should enable.
[15:11.800 --> 15:13.800]  Hello again.
[15:13.800 --> 15:24.320]  So yeah, think I was about done with this slide and going on.
[15:24.320 --> 15:30.760]  One key part here is that all of this is already real.
[15:30.760 --> 15:40.800]  So what I showed you in HTML is not exactly what we use internally at Mozilla, but it's
[15:40.800 --> 15:46.920]  effectively the same as how Firefox is now already translated.
[15:46.920 --> 15:52.160]  We have by now literal years of experience of working with tooling like this and seeing
[15:52.160 --> 15:59.960]  how it empowers UI UX development of a relatively complicated piece of software like Firefox
[15:59.960 --> 16:07.280]  to improve itself and to enable easier and better communication between developers and
[16:07.280 --> 16:14.760]  translators and so we're bringing a lot of that knowledge and experience into what we're
[16:14.760 --> 16:23.400]  doing in the Unicode Consultium when designing Message Format 2 which is yes, taking inspiration
[16:23.400 --> 16:34.760]  but also learnings from Fluent and many other systems that make it honestly a better than
[16:34.760 --> 16:39.360]  Fluent currently is for instance which is why we're now pitching that as the really
[16:39.360 --> 16:43.960]  cool sexy thing even though I mean if you're interested it is the currently coolest thing
[16:43.960 --> 16:52.880]  around that's real, this is still in progress, so you know you could be interested in that.
[16:52.880 --> 16:59.600]  As I mentioned the syntax itself for messages is getting defined under the Unicode Common
[16:59.600 --> 17:07.480]  Language Data Repository Technical Committee, it gets complicated in these things and there's
[17:07.480 --> 17:17.320]  an implementation available in ICU72 for Java and the JavaScript proposals, there's two
[17:17.320 --> 17:23.400]  of them at stage one currently for this are progressing in TC39 which is the body that
[17:23.400 --> 17:29.760]  defines JavaScript effectively and there's a polyfill package for JavaScript if you
[17:29.760 --> 17:34.480]  want to start playing around with what Message Format 2 looks like and how you can work with
[17:34.480 --> 17:45.200]  it but yeah, all of this is of course completely public, all of the repositories, all of the
[17:45.200 --> 17:51.280]  work standards are being developed completely in the open and I mean honestly localization
[17:51.280 --> 17:57.400]  is one of those weird places where we don't need to filter anyone on credentials for like
[17:57.400 --> 18:04.760]  anything because in terms of who wants to actually participate in the standards actions
[18:04.760 --> 18:09.400]  and standards work it's enough that you show up and you show some level of interest and
[18:09.400 --> 18:18.520]  we'll let you in in all the like inside clubs and because there aren't any, it's a community
[18:18.520 --> 18:24.680]  where really you can, if you're interested you should not be afraid of someone saying
[18:24.680 --> 18:31.040]  no you don't belong here because you do, we need always more people participating.
[18:31.040 --> 18:38.320]  Yeah, there's links to me as well and also this talk is available at the URL there at
[18:38.320 --> 18:58.360]  the bottom, it's also attached to the talk on Pentebarf, but yeah, that was me.
[18:58.360 --> 19:21.960]  Are there any questions?
[19:21.960 --> 19:31.400]  The question is what really makes message format to better than fluent and one particular
[19:31.400 --> 19:40.080]  example is when you get to complicated stuff like this, is having the effectively enforcing
[19:40.080 --> 19:47.000]  the data structure that you end up getting from this to be one that contains full messages
[19:47.000 --> 19:54.080]  that you end up representing to translators.
[19:54.080 --> 20:02.200]  Other than this it gets into really nitty gritty details, the other big benefit of message
[20:02.200 --> 20:10.560]  format to over fluent is that message format to is becoming a unicode standard rather than
[20:10.560 --> 20:31.880]  effectively a project built entirely from within Mozilla.
[20:31.880 --> 20:37.400]  So the question here is about seeing the sort of typing that you see, the colon number
[20:37.400 --> 20:44.680]  and the colon relative time and actually the colon gender is the same sort of thing here.
[20:44.680 --> 20:49.400]  What are those and are these custom or centrally defined?
[20:49.400 --> 20:55.120]  And the answer is kind of yes and no and it's complicated because what you're looking at
[20:55.120 --> 21:00.000]  here are effectively functions that act a little bit like types but they're not exactly
[21:00.000 --> 21:01.000]  like types.
[21:01.000 --> 21:06.160]  They're declaring for example that the count that we're getting, let's handle it as a number
[21:06.160 --> 21:11.680]  but also let's in the value of it that we end up assigning to count other use an offset
[21:11.680 --> 21:12.920]  of one.
[21:12.920 --> 21:18.000]  So it's an operation happening on the input argument count and on the third line in the
[21:18.000 --> 21:24.360]  match for the host's gender we could imagine host being some complicated object that's
[21:24.360 --> 21:30.720]  defining a whole person and we're picking the gender information from that more complex
[21:30.720 --> 21:31.720]  thing.
[21:31.720 --> 21:35.840]  But yes in many cases they work kind of like types.
[21:35.840 --> 21:45.080]  Influent, these are the capital number, capital date time and capital platform functions that
[21:45.080 --> 21:51.960]  can be used in this sort of way as well.
[21:51.960 --> 21:52.960]  Just be loud.
[21:52.960 --> 21:53.960]  I'll repeat your question.
[21:53.960 --> 22:17.640]  I feel like people are going to start saying like, okay, we can put links in now and then
[22:17.640 --> 22:24.640]  it sort of escalates to what actually in this locale this whole structure of the page doesn't
[22:24.640 --> 22:29.800]  make any sense anymore so we have to kind of like switch things around a lot based on
[22:29.800 --> 22:36.800]  locale and I'm wondering if you have any thoughts on like where what's out of scope here perhaps
[22:36.800 --> 22:44.800]  and if there are any other tools in development that you know of that kind of like are exposed
[22:44.800 --> 22:54.800]  to not just message forwarding on small sentences or whatever but also restructuring pages based
[22:54.800 --> 22:58.480]  on different locale.
[22:58.480 --> 23:04.200]  So if I've understood the question is what happens when you come from a when you have
[23:04.200 --> 23:11.520]  a complicated thing like a whole page that you're translating and in comparing the source
[23:11.520 --> 23:17.600]  locale and the target locale, the target locale ends up having very different structure that
[23:17.600 --> 23:23.960]  might you know be go much deeper I suppose than just the simple link that I'm showing
[23:23.960 --> 23:27.360]  in this example of how does this really work.
[23:27.360 --> 23:33.000]  The answer is it's complicated and it depends on your use case.
[23:33.000 --> 23:42.320]  This work in particular is trying to build tools that could enable that sort of representation
[23:42.320 --> 23:50.720]  within message format 2 so you could end up somewhere really complicated but you probably
[23:50.720 --> 23:52.520]  don't want to.
[23:52.520 --> 23:59.400]  You're probably in that sort of a situation needing to build more tools that are more
[23:59.400 --> 24:01.160]  specific to the use case that you have.
[24:01.160 --> 24:06.240]  When you have when you need to reformat a whole page in order to do work with a specific
[24:06.240 --> 24:11.360]  locale it's there is no universal answer to this.
[24:11.360 --> 24:16.200]  This is the closest thing but I don't know where it's really going to go.
[24:16.200 --> 24:20.480]  We have a question in the live stream.
[24:20.480 --> 24:24.840]  Translators often are not programmers they already struggle when translating strings
[24:24.840 --> 24:28.120]  with HTML tags and other technical terms.
[24:28.120 --> 24:34.560]  The message format curly braces syntax might be difficult to understand and error prone.
[24:34.560 --> 24:40.720]  So here we're talking about something let's take this example of if you put this in front
[24:40.720 --> 24:46.880]  of a translator yeah you don't.
[24:46.880 --> 24:49.640]  This is not really what we want to do.
[24:49.640 --> 24:58.080]  What we want to do is create a format that enables a like HTML a representation of something
[24:58.080 --> 25:09.280]  like a message in a way that is relatively readable but is not necessarily easy to edit
[25:09.280 --> 25:13.320]  and modify for someone who doesn't exactly know what they're dealing with.
[25:13.320 --> 25:18.800]  A little bit like what happens if you take JSON and put it into a Word document and
[25:18.800 --> 25:24.560]  then you start editing it and then you have to figure out that oh there's a curly quote
[25:24.560 --> 25:26.840]  somewhere that ended up screaming.
[25:26.840 --> 25:32.320]  This sort of thing can happen entirely well when you end up dealing with complicated messages
[25:32.320 --> 25:33.680]  like this.
[25:33.680 --> 25:40.640]  So the answer here is that you end up using tooling that gets this to not be presented
[25:40.640 --> 25:49.640]  as one thing to a translator but three yeah in this case three or more different messages
[25:49.640 --> 25:59.240]  where you end up asking a translator wants to translate name invited you to her party
[25:59.240 --> 26:06.640]  on relative date and then a second to ask them to translate name invited you to his
[26:06.640 --> 26:14.160]  party on relative date and in Finnish allow a translator because Finnish doesn't he and
[26:14.160 --> 26:16.160]  she translated the same word.
[26:16.160 --> 26:20.680]  So in Finnish the equivalent of this message would end up being effectively just the third
[26:20.680 --> 26:25.280]  case without the whole matching because the structure of the language works differently.
[26:25.280 --> 26:31.200]  So you do end up when working with messages of this level of complexity effectively needed
[26:31.200 --> 26:38.280]  to rely on tooling but the wonderful thing about message format two is that we can transform
[26:38.280 --> 26:45.240]  this representation of this message into any other representation of this message that's
[26:45.240 --> 26:49.560]  hopefully going to work with whatever tooling is then available for the actual translation
[26:49.560 --> 26:51.280]  work to happen in.
[26:51.280 --> 26:59.120]  So XLIF two for instance or other targets that are commonly supported by software used
[26:59.120 --> 27:08.280]  for translation or some really simple representation that can be mapped then back to this but still
[27:08.280 --> 27:14.120]  allows a translator to just see a simpler thing at once rather than a really complicated
[27:14.120 --> 27:17.200]  thing.
[27:17.200 --> 27:21.920]  Think there's more questions but are we out of time?
[27:21.920 --> 27:24.400]  Two minutes.
[27:24.400 --> 27:25.400]  Guy in front, yellow.
[27:25.400 --> 27:36.400]  My question is I can guess that you are targeting the new message format as a successor of all
[27:36.400 --> 27:40.920]  previous attempts at message format.
[27:40.920 --> 27:49.600]  It is relatively easy to make sure that everything representable in previous message format is
[27:49.600 --> 27:51.760]  representable in the new one.
[27:51.760 --> 27:58.800]  How are you solving the problem that you are really encompassing all the different languages
[27:58.800 --> 27:59.800]  in the world?
[27:59.800 --> 28:06.560]  Because like all the examples we saw were in English perhaps some of the others might
[28:06.560 --> 28:11.600]  be like French or another in the European language.
[28:11.600 --> 28:21.880]  The case here is just for female or male languages with much more complicated noun systems.
[28:21.880 --> 28:30.000]  In some languages you might be writing a single message in several writing systems.
[28:30.000 --> 28:41.080]  How do you make sure that the new message format encompasses all these different strange
[28:41.080 --> 28:44.920]  cases for localization?
[28:44.920 --> 28:48.720]  If I understand the question right you are asking how do you make sure that this isn't
[28:48.720 --> 28:53.680]  really what seems to work for English in a couple of languages around English but hopefully
[28:53.680 --> 28:55.200]  all the languages?
[28:55.200 --> 28:58.800]  Or a sizeable number of languages.
[28:58.800 --> 29:05.520]  The short answer here is that with Fluent we are already doing exactly this using representation
[29:05.520 --> 29:07.880]  of messages that is very close to this.
[29:07.880 --> 29:15.520]  For instance, at Mozilla from this experience we can say that the simpler than this structure
[29:15.520 --> 29:21.200]  that we have for Fluent ends up working in all of the languages that we need to deal
[29:21.200 --> 29:23.240]  with through Fluent.
[29:23.240 --> 29:31.440]  We need to deal with Fluent which is about 100 for Firefox, 200 overall for all of the
[29:31.440 --> 29:36.360]  different projects that we are currently translating.
[29:36.360 --> 29:45.880]  Separately from this the work being done for message format too is by no means done really
[29:45.880 --> 29:52.560]  from an English language point of view.
[29:52.560 --> 29:59.680]  With the main contributors currently working on the specification my background is Finnish,
[29:59.680 --> 30:05.120]  there's a Polish guy, then there's a Romanian, then there's a Sri Lankan and there's a couple
[30:05.120 --> 30:11.360]  of others who are on the periphery of this who are from a much wider variety of backgrounds
[30:11.360 --> 30:12.360]  than this.
[30:12.360 --> 30:19.960]  So, we are bringing in ensuring that these sorts of considerations are actively being
[30:19.960 --> 30:23.880]  remembered to be taken care of.
[30:23.880 --> 30:28.360]  To some extent we are relying on the expertise that we have, to some extent we are relying
[30:28.360 --> 30:34.120]  on the experience we have with working with similar formats than what we are presenting
[30:34.120 --> 30:35.120]  here.
[30:35.120 --> 30:43.520]  But also we are trying to build a core specification for message formatting that is sufficiently
[30:43.520 --> 30:50.320]  small but modular and powerful to then enable the support later on that is required by human
[30:50.320 --> 30:51.320]  languages.
[30:51.320 --> 30:56.000]  We are trying to limit to just being able to support human languages but it might go
[30:56.000 --> 31:00.040]  a little bit beyond that too.
[31:00.040 --> 31:05.440]  I think we are out of time, I am very happy to have people come and ask me questions after.
[31:05.440 --> 31:17.240]  Thank you.