I've worked on a web application that operates in 11 languages as of writing this article which has exposed me to numerous problems that relate to localization.  I'm using the handlebars implementation of Formatjs in my examples. I've also used their React implementation.

DRYing up our localizations.

As developers, we want to make our code a DRY as possible.  This can apply to even the smallest piece of code that we might reuse.  It helps maintenance and can reduce errors.

When we try to apply this to localizations we end up with a pattern will fail. For example, take a list of strings for a permissions page.

The user can edit images
The user can edit posts
The user can edit pages
The user can edit events
...

It can be tempting as a developer to simply have a single localization just concatenate the last value.

// localizations string
theUserCanEdit: "The user can edit"

// Handlebars example
{{#each element in elements}}
	{{formatMessage (intlGet "theUserCanEdit")}} {{element}}
{{/each}}

// results
The user can edit images
The user can edit posts
The user can edit pages
The user can edit events

This seems fine.  But what if we change to a language with a different grammatical structure that places the object of editing in the front of the sentence.  Let's say we have a new language called Yoda english. This implementation immediately breaks down.  

All concatenation patterns have this problem in localization and should be avoided.

Instead, you can create better localization strings.

// regular english localizations string
theUserCanEdit: "The user can edit {element}"

// yoda english localizations string
theUserCanEdit: "{element} can edit the user"


// Handlebars example
{{#each element in elements}}
	{{formatMessage (intlGet "theUserCanEdit")
		element=element
	}}
{{/each}}

// results
The user can edit images -> images can edit the user
The user can edit posts  -> posts can edit the user
The user can edit pages  -> pages can edit the user
The user can edit events -> events can edit the user

But wait there's more!

Let's make this a little more interesting.  In my example above I've assumed that the value of an element is the same in all languages.  That's never the case. More often than not it's not even appropriate to use in English.

If our code uses constants to represent these values we can localize them with our locale strings.

Let's assume we receive the following values in our array of elements.

elements = ['img', 'page', 'post', 'event']

Now we can change our localization string to check against those constant values. Here is what the English localization might look like:

// localizations string
theUserCanEdit: `The user can edit { element, select, img {images}
						    page {pages}
						    post {posts}
						    event {evnets}
						    other {things} }`

// Handlebars example
{{#each element in elements}}
	{{formatMessage (intlGet "theUserCanEdit")
		element=element
	}}
{{/each}}

We accomplish the same result but now when we create our localization string for French we can translate the values of images, pages, posts, and events appropriately.  Additionally, I've included a value for other in the localization.  If we get an unexpected value we can still supply a localization.  There are many other helpers in the formatjs library and I encourage you to check them out :)