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.
if
s" to "have two apps"