#47671 closed feature request (wontfix)
Add a "user languages" folder for translations
Reported by: | Adrian2k7 | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | I18N | Keywords: | close |
Focuses: | Cc: |
Description
Hello,
Actual state
There are currently 2? official locations for translations.
- Folder within plugin/theme
- Folder wp-content/languags
The problem with these two is,
- that both are managed automatically and users are not able to edit them, without risking loosing translations.
- A plugin is needed for just a few translations
- Plugins can't work together on the same language base
Suggestions
Introduce an additional language folder, the user can put custom translations files into, which are not removed by updates ...
I.e.
wp-content/languages/custom
This would also be nice, as plugins may all use this folder and allow some kind of interoperability:
- i.e. the basic user could use Loco Translate, but the power user could use PoEdit to edit the same files
- an upgrade from Loco Translate to i.e. a multilingual site with WPML might be easier
Change History (3)
#2
@
8 months ago
- Keywords close added
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
IMO this is plugin territory. There clearly is a lack of interest for such a feature in core, and adding such solution would only add a lot of unnecessary file lookups to core, which is bad for performance.
#3
@
8 months ago
@swissspidy I'm with you, that there is lack of interest ;)
It is already possible to provide simple translations using drop-in php file.
Just not user-friendly.
Maybe in an English world, there is really no need. I regularly have the requirement to alter or add missing German translations, and just use Loco Translate for only a couple of strings.
But file lookup really is no issue... sure with mo files, but that is not a file lookup issue, more bad architecture issue.
You just posted a news yesterday about improving the i18n performance, in a way that the "number" of files doesn't really matter.
Previously: #17266, #28571.