In search of the DX in i18n
I18n is one of these areas that seem to be treated as an afterthought. In general you have other concerns when starting to build out an application. Things like which programming language or framework should we use? or how do we model our data? are more important questions in the initial phase. If the core area of your business is not I18n itself, then there will always be more important areas that will require focus.
More often than not I18n comes later into play, like when your application has gained some traction or it has proven a concept and it’s time to expand to new territories and regions. I18n and L10n are intertwined and we will not go into detail about the specifics, but assume we are talking about both from here on out.
So while we already have good to very good tooling in the form of advanced IDEs, CD/CI integration with our version control system or programming languages and frameworks that come with LSPs and great IDE integration, we don’t have the same experience when it comes to I18n. In this post we will try to explore some reasons and what we could do to improve the I18n developer experience.
One thing that you will notice when talking about I18n is that we don’t have a concrete concept when we talk about our translations. We have differing standards for how strings, pluralization, time, money or number formatting is handled. Even when we talk about GNU gettext , we might still be dealing with different language specific implementations, placeholders for example might differ between the different language flavors.
