Language Hierarchy
Most software products eventually target more than one regional variant of a language. Spanish is spoken differently in Spain, Mexico, and Argentina. English in the United States differs from English in the United Kingdom and Australia. Without a structured approach, teams either maintain entirely separate translation files for each variant — duplicating most of the work — or use a single file and accept that some strings will feel wrong to some audiences. Language Hierarchy solves this by letting you define parent-child relationships between languages.
The concept is straightforward: a parent language holds the base strings that apply across all its variants. Child languages inherit every string from the parent and only need their own value where the regional variant differs. For example, you might set English as the root, with en-US and en-GB as children. The word "color" would be overridden in en-GB to "colour", but the hundreds of strings identical between the two variants are inherited automatically, with no duplication.
The same pattern works at any depth. A Latin American Spanish parent (es-419) could have Mexican Spanish (es-MX) and Colombian Spanish (es-CO) as children, each inheriting from the parent and only specifying strings where local vocabulary or phrasing genuinely differs.
In Language Monster, hierarchy is built directly into the project structure. When a translator works on a child language, they see which strings are inherited and which have been overridden locally, making it clear what requires attention after a source update. When a string changes in the parent, child languages are flagged automatically so nothing goes stale without being noticed.
The result is significantly less duplicated work, more consistent translations across related locales, and a cleaner project structure that scales as you add new regional variants over time.
