I appreciate you putting in the time to show your findings when composing your question. My projects have never really needed anything more than to support
en_US. I know there are plenty of stores out there that support multiple languages… So, my experience is somewhat limited. But I’m happy to share what I do “know”.
Like you, I’ve had to make similar changes to my projects. Compared to M1, M2 is very compartmentalised, which is a good thing. The bad part is having to work it all out
My favourite fact about the new translation system is that it’s now referred to as “i18n”, which is short for “internationalisation” (“i” followed by 18 letters then “n”). I don’t know why I find that so cool…
Anyway, being too lazy to research i18n in full because I’ve never had to do any “true” translating, I stumbled my way around. But this is what I’ve learned so far:
- i18n can be initialised in the child theme just as you mentioned.
- i18n can also be initialised per module within
- Some labels are hard-coded in and can’t be translated via 918n (A side effect from lazy coding)
Based on the first 2 points (above), here are some examples of where i18n files can be initialised:
vendor/vendor/module/i18n/(Never edit anything in this folder)
Because there are essentially 3 locations that i18n files can be initialised from, Magento always checks the
app/vendor files first. Then it checks the
app/design files for any overrides.
One thing I don’t know is what takes priority out of
app/design. Perhaps you can tell me?
i18n “technically” gets cached in 2 locations, one of which is the standard cache which can be cleared in System > Cache Management. Fairly obvious I know…
The second location is the generated static files. I learned this the hard way, believe me… Sometimes I would update i18n files and get frustrated because I couldn’t see my changes. Even after updating several files in several locations. In the end I stumbled across this.
When I redeployed my static files, I would have to specify both the default
en_US and the
en_GB languages. The commands vary slightly depending what mode you’re in:
bin/magento setup:static-content:deploy en_GB en_US
bin/magento setup:static-content:deploy en_GB en_US -f
Even though I only support
en_GB, I think I still have to generate
en_US because that’s the default fallback language but I could be wrong.
Anyway, whenever I make an i18n amendment I always run that command before previewing it.
Existing en_GB language pack
As a starting point for creating an
en_GB language pack and essentially “reverse engineering” it, I use this module via composer. This module should give you everything you need in order to create your own language pack from scratch (including the basic files required to build a module).
I was too lazy to make my own pack from scratch, but there was still some translations that I wanted to tweak. So I broke rule #1 to achieve this and edited the core csv files in the module. Which means that if this module is ever updated, it would write over all of my changes. But I still did it anyway because I have backups of those files and the chances of this particular module being updated are slim. Practice what I preach not what I do
I’m not sure what else I can share with you as I clearly have some knowledge gaps in this topic. Hopefully, you’ll be able to either use or reverse-engineer that module I shared. And you should find that static-content command helps as well. If you learn anything else along the way, please share as I’d like to know.