Make WordPress Core

Opened 5 years ago

Closed 8 months ago

Last modified 8 months ago

#47671 closed feature request (wontfix)

Add a "user languages" folder for translations

Reported by: adrian2k7's profile 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 @swissspidy
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 @Adrian2k7
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.

Note: See TracTickets for help on using tickets.