Our team has started to add gettext localization function calls for various strings inside of our project. We are not actively translating but hedging our bets that we’d like to at some point in the not-too-distant future.
We are currently discussing domain use and we don’t have strong guidance on how to best define the domain structure within our app. How many domains should we make? When is a domain too large? Why should we break up into domains?
There is a general feeling that we should avoid one single domain but I’d like to ask for feedback from folks who have actively translated a project in the past for what they recommend.
I don’t think size should matter at all. Preventing ambiguity is the driving factor for splitting up domains. You’d want to split appart where one an the same string might need to be translated differently.
I agree with the above. As an example, we’re building an application with two separate front-ends, hosted on two different subdomains for different users. But they share the same core (even go to the same context files and use the same ecto schema’s). The same error might be translated differently, as the message is presented to two different populations.
One “mechanical” separation we do is keeping enum translations in a separate domain. These can’t be extracted, and are translated with Gettext.dgettext/4.
But I wouldn’t overthink it. Being prepared by avoiding literal strings in the front-end is 99% of the work. And since it’s so easy to do when starting fresh, and such a pain to add later, I have the tendency to always go through gettext for messages in the front-end, even if only one language is used. Maybe I’m biased living in a country that has three official languages for 10M people, where language is always an issue
