Opened 9 years ago
Closed 9 years ago
#28537 closed enhancement (wontfix)
Child Translations
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | |
| Component: | I18N | Keywords: | |
| Focuses: | Cc: |
Description
Every once in a while a website owner or administrator wants to change a particular word to something else. The way to do it is to edit/create the language files.
This is a workable but deeply unsatisfying solution. For one it takes a LOT of work to find and rename each reference to the particular item individually in POedit. More importantly, all the changes would be wiped off upon updating WordPress. Further, if someone is using WordPress in a non-English language, then they basically have to edit the language file which faces the same overwriting issues.
So, what I propose is this:
A while ago WordPress implemented Child Themes. This has been an immensely successful initiative. We could take inspiration from that and introduce Child Translations.
Essentially, the site admin can create a language file containing ONLY the strings that are different on his/her blog compared to standard version of the translation. This file is placed in /wp-content/languages/child/ or something to that effect. When WordPress loads translations, the ones in the file in the child subfolder takes precedence over those in languages folder....so strings present in the child subfolder mo are loaded from that and the rest of the strings are loaded from the languages mo. When translations are updated the languages mo is overwritten with a new version, but it doesn't matter as the child mo still outranks it.
Change History (3)
#2
@
9 years ago
I don't think this is needed. There are a number of ways around this. I wrote about this a bit on my blog. https://ulrich.pogson.ch/load-theme-plugin-translations
This is already doable using the existing APIs. If you call load_*_textdomain() a second time for the same domain, it'll overwrite the new strings on top of the initial strings. This mo file only needs to include a subset of strings you wish to overwrite.
I don't think it makes sense for this to be done automagically. It's a lot of extra file stat calls for fairly little benefit. But it'd be a cool, easy plugin.