0

I'm working on an app that needs to be localised for two different countries, let's call them Atlantis and Buranda. As well as translating the site into the relevant languages and displaying dates, numbers, etc. in localised formats, the Atlantis region needs a feature to work in a particular way but the Buranda region needs it to work in a different way. For example, an enumeration for "widget type" has different values in each region.

I'd very much like to avoid having lots of branching based on the current locale. What software engineering strategy could help me to achieve that goal?

2
  • 1
    How divergent are these two feature differences? There's a continuum of "have some ifs" to "have two apps"
    – Caleth
    Commented Mar 25, 2022 at 11:17
  • @caleth The differences aren't enough to justify two separate apps. At the moment we're running the same app in separate environments with various features configured per-environment, but this currently limits us to one locale per environment, which isn't sustainable. Commented Mar 25, 2022 at 16:36

2 Answers 2

3

One should approach this the same way like it is done for other kind of customizations: by building the requirements into the application so it can handle them at run time, controlled by configuration switches and/or parameters (instead of trying to abuse different branches in your VCS).

Of course, as you mentioned in the question, localization is a cross-cutting concern and may affect different features, for example:

  • language of all texts in the GUI

  • date format

  • number format

  • behaviour of certain functions

  • requirements in regards to different laws and standards

I would heavily recommend to identify those first, and then create an individual switch or parameter for each feature. Keep this as orthogonal as possible! That way, you can develop and test a switch individually. Think of each switch as a feature on its own!

Finally, you provide the switches in some tabular form, like this:

Feature Country 1 Country 2
language English German
date format yyyy-mm-dd dd.mm.yyyy
number format #.0# #,0#
cookie warning none EU cookie consent

It remains to build an option into your application to pick a country (either at deployment time by you, at installation time by an admin or at any time by the user).

In case you figure out that some of these features should be kept switchable by the users (like the language), regardless of the country, and others should not (like the necessity to show a cookie banner), your application will be prepared for it.

0

Make sure your app can have a different locale for UI and for behaviour. For example a German living in the UK and filling out their tax return may want a German UI, but UK tax rules.

Let the user choose the locale for behaviour, with default = Locale for UI. Or choose when the app is installed, possibly not giving the user a choice.

Give an error message if the chosen locale is not supported by the application.

A reasonably simple way to implement this is having classes that implement behaviour, which can be subclassed for locale specific behaviour. And a factory chosen by locale, which returns instances of appropriate classes depending on the locale.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.