tl;dr: Following on from a rush of success at conquering React contexts, Rik experiments further to see if he can add a ‘reasonably sane’ localization strategy to his app
Localization - why do important things hurt?
I’m not a great fan of inflicting pain on myself. Yet sometimes I have to face up to my fear of pain and take the hits. This is why I believe websites and apps should have localization built into them from the beginning because - in my (limited) experience - taking the hits at the start of a project is much more fun that being mauled to Hell and back when the client asks you to ‘internationalize’ their marvellous app a few months (or years) down the line.
Truth: localization is hard! It’s not just about translating a few strings here and there - when you internationalize a website or app you need to start not from the developer’s point of view, but rather that of the app’s user in China, or Russia, or Argentina. Because User Experience is cultural, not just linguistic.
Now the React community and various businesses have come up with some interesting ways to localize a React app over the years. I expect some of them work really well - I’ve not explored them in any depth because I’ve not (yet) had an opportunity to work on a big international React project.
Some unexpected benefits of localization
There are a couple of benefits to localizing an app or website early, beyond impressing the client with my strategic, long-term view and potential additional profits:
It stops me littering the codebase with hard-coded strings, which are always a bugger to hunt out and fix when the client asks for copy updates.
It helps me order my dictionary files in a way that (possibly) makes the codebase easier to navigate for my imaginary co-workers - because site maintenance is important and lucrative stuff.
I expect there’s other benefits as well - for instance opportunities to practice some fancy React code-splitting to bring site load times down; nobody likes a site that takes 30 seconds to present its landing page innit. Whatever.
Anyway. Doing some localization work with a React app is a learning opportunity for me. And when I’m learning I prefer to code up stuff in Vanilla JavaScript where possible - even if there’s already a library which does this stuff perfectly. When I use a library, what I learn is how to use that library; I miss out on all the fundamental stuff about how something needs to be done and why it needs to be done this way, not that way.
As before, I’ll present my thoughts on the how and the why as comments in the code. I shall use the codebase I developed in my Coming to terms with React context post, where I did combat with React’s new context things (and came out ahead on points). It turns out that the solution I found only requires me to add 3 new files to the codebase, and an update to just one existing Component.
Rik’s code for adding localization to his demo Reace app
The first new file is a React Higher Order Component which I shall call Copy.js
1 | import React, { Component } from 'react'; |
Now I need a locale dictionary file to act as the default. This file I shall put in a sister folder to my Components folder, calling it England.js
1 | const England = { |
It’s not much of an experiment if I don’t have a second locale to swap between. I shall call this locale Abroad.js, where everyone speaks Pirate.
1 | const Abroad = { |
The existing Component which needs updating is HelloRik.js
1 | import React, { Component } from 'react'; |
So does it work?
It works for me!
As ever, I am not a React expert. If people spot obvious flaws in my code then please don’t hesitate to let me know in the comments.