Skip to main content

In The News

messageformat is Working Hard to Make Themselves Obsolete

By Blog, In The News, messageformat, Project Update

This post originally appeared on DZone on September 1, 2020.

messageformat is an OpenJS Foundation project that handles both pluralization and gender in applications. It helps keep messages in human-friendly formats, and can be the basis for tone and accuracy that are critical for applications. Pluralization and gender are not a simple challenge, and deciding on which message format to implement can be pushed down the priority list as development teams make decisions on resources. However, this can lead to tougher transitions later on in the process with both technology and vendor lock-in playing a role. 

Quick note: The upstream spec is called ICU MessageFormat. ICU stands for International Components for Unicode: a set of portable libraries that are meant to make working with i18n easier for Java and C/C++ developers. If you’ve worked on a project with i18n/l10n, you may have used the ICU MessageFormat without knowing it. 

To find out more about messageformat, I spoke with Eemeli Aro, Software Developer at Vincit, and OpenJS Cross Project Council (CPC) member. Aro maintains the messageformat libraries, and actively participates in various efforts to improve JavaScript localization. Aro spoke on “The State of the Art in Localization” at last year’s Node+JS Interactive. Aro is an active participant in ECMA-402 processes, runs the monthly HelsinkiJS meetups, and helps organise React Finland conferences. 

How do formats deal with nuances in language? 

It’s all about choices. Variance, e.g. how the greeting used by a program could vary from one instance to the next, gets dealt with by having the messaging format that you’re using support the ability to have choices. So you can have some random number coming in and depending on the choice of that random number, you select one of a number of choices. This functionality isn’t directly built into ICU MessageFormat, but it’s very easily implementable in a way that gets you results. 

We need to decide how we deal with choices and whether you can have just a set number of different choice types. Is it a sort of generic function that you can define and then use? It’s an interesting question, but ICU MessageFormat doesn’t yet provide an easy, clear answer to that. But it provides a way of getting what you want. 

What are the biggest problems with messaging formats?

Perhaps the biggest problem is that while ICU MessageFormat is the closest we have to a standard, that doesn’t mean it is in standard use by everyone. There are a number of different other standards. There are various versions that are used by a number of tools and workflows and other processes in terms of localization. The biggest challenge is that when you have some kind of interface and you want to present some messages in that interface, there isn’t one clear solution that’s always the right one for you. 

And then it also becomes challenging because, for the most part, almost any solution that you end up with will solve most of the problems that you have. This is the scope in which it’s easy to get lock-in. Effectively, if you have a workflow that works with one standard or one set of tools or one format that you’re using, then you have some sort of limitation. Eventually, at some point, you will want to do something that your systems aren’t supporting. You can feel like it’s a big cost to change that system, and therefore you make do with what you have, and then you get a suboptimal workflow and a suboptimal result. Eventually, your interface and whole project may not work as well. 

It’s easy to look at messageformat and go, “That’s too complicated for us, let’s pick something simpler.” You end up being stuck with “that something simpler” for the duration of whatever it is that you’re working on. 

You’re forced to make a decision between two bad options. So the biggest challenge is it would be nice to have everyone agree that “this is the right thing to do” and do it from the start! (laughs) 

But of course that is never going to happen. When you start building an interface like that, you start with just having a JSON file with keys and messages. That will work for a long time, for a really great variety of interfaces, but it starts breaking at some point, and then you start fixing it, and then your fix has become your own custom bespoke localization system. 

Is technology lock-in a bigger problem than vendor lock-in? 

Technology lock-in is the largest challenge. Of course there is vendor lock-in as well, because there are plenty of companies offering their solutions and tools and systems for making all of this work and once you’ve started using them, you’re committed. Many of them use different standards than messageformat, their own custom ones. 

In the Unicode working group where I’m active, we are essentially talking about messageformat 2. How do we take the existing ICU MessageFormat specification and improve upon it? How do we make it easier to use? How do we make sure there’s better tooling around it? What sorts of features do we want to add or even remove from the language as we’re doing this work? 

messageformat, the library that I maintain and is an OpenJS project, is a JavaScript implementation of ICU MessageFormat. It tries to follow the specification as close as it can. 

Does using TypeScript help or hurt with localization? 

For the most part, it works pretty well. TypeScript brings in an interesting question of “How do you type these messages that you’re getting out of whatever system you’re using?” TypeScript itself doesn’t provide for plugins at the parser level, so you can’t define that. When there’s input in JavaScript, for example, for a specific file, then you can use specific tools for the different types that are coming out of it. Because messages aren’t usually one by one by one. You have messages in collections, so if you get one message out of a collection in JavaScript, you can make very safe assumptions about what the shape of that message is going to be. 

But of course in TypeScript you need to be much more clear about what the shape of that message is. And, if for whatever reason not everything is a string, then it gets complicated. 

It’s entirely manageable. You can use JavaScript tools for localization in a TypeScript environment, there are just these edge cases that could have better solutions than we currently have but work on those kind of requires some work on TypeScript behalf as well.

Should open source projects build their own solution for localization? 

I think this is one of those cases where it’s good to realize that this is JavaScript. If there’s a problem you can express briefly, you go look and you’ll find five competing solutions that are all valid in one way or another. Whatever your problem or issue is, it is highly likely that you will find someone else has already solved your problem for you, you just need to figure out how to adapt their solution to your exact problem. 

There are a number – like three or four – whole stacks of tooling for various environments for localization. And these are the sorts of things that you should be looking at, rather than writing your own. 

How is the OpenJS Foundation helping with localization?

Well, along with messageformat OpenJS hosts Globalize which utilizes the official Unicode CLDR JSON data. 

The greatest benefit that I or the messageformat project is currently getting from the OpenJS Foundation is that the Standards Working Group is quite active. And with their support, I’m actively participating in the Unicode Consortium working group I mentioned earlier where we are effectively developing the next version of the specification for messageformat. 

How far off is the next specification for messageformat?

It’s definitely a work in progress. We have regular monthly video calls and are making good progress otherwise. I would guess that we might get something in actual code maybe next year. But it may be actually longer than that for the messageformat to become standard and ready. 

How will localization be handled differently in 3-5 years? 

The messageformat working group didn’t start out under Unicode, it started out under ECMA-402. That whole work started from looking to see what we should do about adding support for messageformat to JavaScript. And this is one of the main expected benefits to come out of the Unicode messageformat working group. In the scope of 3-5 years, it is reasonable to assume that we are going to have something like intl.MessageFormat as a core component in JavaScript, which will be great! 

Effectively, this is also coming back to what the OpenJS Foundation is supporting. What I’m primarily trying to push with messageformat is to make the whole project obsolete! Right now we’re working on messageformat 3, which is a refactoring of some breaking changes. But hopefully a later version will be a polyfill for the actual Intl.MessageFormat functionality that will come out at some point. 

On a larger scale, it’s hard to predict how much non-textual interfaces are going to become a more active part of our lives. When you’re developing an application that uses an interface that isn’t textual, what considerations do you really need to bring in and how do you really design everything to work around that? When we’re talking about Google Assistant, Siri, Amazon Echo, their primary interface is really language, messages. Those need to be supported by some sort of backing structure. So can that be messageformat? 

Some of the people working on these systems are actively participating in the messageformat 2 specifications work. And through that, we are definitely keeping that within the scope of what we’re hoping to do. 

Try it out now

To install the core messageformat package, use:

npm install –save-dev messageformat@next

This includes the MessageFormat compiler and a runtime accessor class that provides a slightly nicer API for working with larger numbers of messages. More information:

What’s New With Node? Interview With Bethany Griggs, Node.js Technical Steering Committee

By Blog, In The News, Node.js
Bethany Griggs

In a recent interview with DZone, Bethany Griggs, Node.js Technical Steering Committee member and Open-source Engineer at IBM gave some insight into the recent Node.js v14 release as well as the latest in Node.js overall. Topics covered include changes with the project pertaining to contributor onboarding, getting started in Node.js, challenges, and highlights of Node.js v14. Node.js is an impact project of the OpenJS Foundation.

Bethany has been a Node Core Collaborator for over two years. She contributes to the open-source Node.js runtime and is a member of the Node.js Release Working Group where she is involved with auditing commits for the long-term support (LTS) release lines and the creation of releases. 

Bethany presents and runs workshops at international conferences, including at NodeSummit, London Node.js User Group, and NodeConfEU.

Read the full article here:

OpenJS Foundation congratulates GitHub and npm

By Announcement, Blog, In The News

The stability and security of an open source package management public registry for JavaScript developers has been a constant theme that I hear from communities across the OpenJS Foundation. Today, it was announced GitHub will be acquiring npm with a commitment to keep the public registry open. This is positive on several fronts, and a logical step to ensure confidence in the npm public registry for JavaScript developers.

GitHub is already used extensively by JavaScript communities, and is well-aligned to support this vast ecosystem. In fact, the 2019 GitHub Octoverse survey has JavaScript as the most popular programming language by repo contributors. Running a reliable service at the npm size is something that GitHub can surely do well.

Companies large and small trust GitHub. Because 80-90 percent of all modern apps are built with open source, and over 95% of the world’s websites use JavaScript, this acquisition further bolsters confidence in JavaScript as a critical technology to modern web, cloud and AI apps. 

Last but not least, I know and trust the GitHub leadership, including Nat Friedman, Erica Brescia, Martin Woodward and more who for many years have been collaborating across the industry for the greater good. We’ve worked with them in the trenches on OSS projects and community engagements, with friendship along the way. They have the experience to build upon the important contributions by many, which made npm the leading open source package management resource it is today. 

Congratulations GitHub and npm! We look forward to continuing our work with you all, together with our members and JS communities in new and productive ways.

[Disclosure: I’m a recent Microsoft alum, GitHub’s parent company]

Robin Ginn

Executive Director, OpenJS Foundation

Electron joins the OpenJS Foundation

By Blog, Event, In The News, Node+JS Interactive, Project Update

The popular web framework for building desktop apps plays an important role in the adoption and development of JavaScript.

MONTREAL- December 11, 2019 – The OpenJS Foundation today announced the open source web framework Electron has been accepted into the Foundation’s incubation program. Electron, an open source framework created for building desktop apps using JavaScript, HTML, and CSS, is based on Node.js and Chromium. Additionally, it is widely used on many well-known applications including Discord, Microsoft Teams, OpenFin, Skype, Slack, Trello, Visual Studio Code, and many more

The OpenJS Foundation, which provides vendor-neutral support for sustained growth within the open source JavaScript community, delivered the news at the Foundation’s flagship event, Node+JS Interactive, in Montreal. 

“We’re heading into 2020 excited and honored by the trust the Electron project leaders have shown through this significant contribution to the new OpenJS Foundation,” said Robin Ginn, Executive Director of the OpenJS Foundation. “Electron is a powerful development tool used by some of the most well-known companies and applications. On behalf of the community, I look forward to working with Electron and seeing the amazing contributions they will make.” 

Electron’s cross-platform capabilities make it possible to build and run apps on Windows, Mac, and Linux computers. Initially developed by GitHub in 2013, today the framework is maintained by a number of developers and organizations. Electron is suited for anyone who wants to ship visually consistent, cross-platform applications, fast and efficiently. 

“We’re excited about Electron’s move to the OpenJS Foundation and we see this as the next step in our evolution as an open source project,” said Jacob Groundwater, Manager at ElectronJS and Principal Engineering Manager at Microsoft. “With the Foundation, we’ll continue on our mission to play a prominent role in the adoption of web technologies by desktop applications and provide a path for JavaScript to be a sustainable platform for desktop applications. This will enable the adoption and development of JavaScript in an environment that has traditionally been served by proprietary or platform-specific technologies.”

“We’re committed to open source and developer collaboration, and thrilled for Electron to be a part of the Foundation’s incubation program,” said Sarah Novotny, Partner PM Manager, Azure, Microsoft. “We look forward to further enhancing the open source project for contributors, maintainers, and developers building on the framework; while exposing the project to a broader audience.”

“Electron is a great example of how interconnected the JavaScript ecosystem can be. Built on Chromium and Node.js, Electron is an amazing tool that empowers developers to create great cross-platform desktop experiences,” said Myles Borins, OpenJS Foundation Board member and Developer Advocate at Google. “It’s extremely exciting to see this project join the Foundation and stepping towards a more open governance model.”

“The Cross Project Council is thrilled to bring Electron into the OpenJS Foundation community,” said Joe Sepi, Cross Project Council Chair, and Open Source Engineer & Advocate at IBM. “Collectively, we are building something sustainable for the long-term benefit of community members and end-users. We are excited to work with Electron, and to have them be part of our mission.”

“On behalf of the OpenJS Foundation Board of Directors, it’s my pleasure to welcome Electron as the newest incubating project to the Foundation,” said Todd Moore, OpenJS Foundation Board Chair and Vice President of Open Technology and Developer Advocacy at IBM. “Bringing Electron into the Foundation is a great way to cap 2019, and continue to build our momentum into next year.”

Representatives from Electron will be featured in both a keynote and breakout session at Node+JS Interactive. 

  • On December 12, at 11:20 am ET, Felix Rieseberg will present a breakout session titled “Electron: Desktop Apps with JavaScript,” and give a technical introduction to Electron. Building a small code editor live on stage, he’ll cover the basics and explain both benefits and challenges of using Node.js and JavaScript to build major desktop applications. (ADD LINK)

About OpenJS Foundation 

The OpenJS Foundation is committed to supporting the healthy growth of the JavaScript ecosystem and web technologies by providing a neutral organization to host and sustain projects, as well as collaboratively fund activities for the benefit of the community at large. The OpenJS Foundation is made up of 32 open source JavaScript projects including Appium, Dojo, jQuery, Node.js, and webpack and is supported by 30 corporate and end-user members, including GoDaddy, Google, IBM, Intel, Joyent, and Microsoft. These members recognize the interconnected nature of the JavaScript ecosystem and the importance of providing a central home for projects which represent significant shared value.