#3369 closed enhancement (maybelater)
Change plugin default language
Reported by: | danieltj | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Plugin Directory | Keywords: | |
Cc: |
Description
Something I've noticed a few times is when some plugin authors write a plugin in their native language first, say German for example. However, they still need to translate the plugin from German (en_US) into German (de_DE). Not only does this cause issues with new users wanting to try the plugin but not speaking German, it means that there is technically no English version.
I'd like to propose that the plugins language can be defined somewhere (ideally not the readme) where the author(s) can set the default language. This would however mean there would need to be an actual instance of en_US for this to work.
Another example of this, albeit not too much of an issue is that my own plugins are written in British English (en_GB). So technically the plugins are translated in British English twice but the plugin page reports that it's translated in en_US and en_GB which is false.
Change History (4)
#1
@
7 years ago
This ticket was mentioned in Slack in #meta by tellyworth. View the logs.
7 years ago
#3
@
7 years ago
- Resolution set to maybelater
- Status changed from new to closed
By and large, this is not something that is easily fixed. It doesn't have to do with the plugin or theme directories directly, but more about the translation system of glotpress.
Basically, our installs of Glotpress doesn't have an "en-us" project. We don't translate anything to en-us, we start from there. This is simply because WordPress itself was written in en-us.
So while it would be possible for that starting point to be shifted around for any particular project, that functionality simply does not exist in the software right now. The plugin directory can't implement it on its own, because it's not the plugin directory doing the translating.
So, allowing for a "default" of something else would mean changing Glotpress in probably a pretty fundamental way, which also would involve shifting around all existing data, and so forth. It would be a pretty large project.
In the long term, sure, allowing for projects to use other languages as starting points makes perfect sense. It's probably something that will be implemented in the future. It'll have to be something implemented in Glotpress first, and migrated to on the translate.wordpress.org systems, and tested extensively, and then we'd build some way into the directories to allow them to choose a default, somehow. But that's a big project and so probably a long time away.
For now, I'll close this with a "maybelater", because while it is a good idea, it's a much larger amount of effort to do than you might expect.
#4
@
7 years ago
It's also worth noting that it is questionable if the WordPress core itself supports using en_US as a locale and having translations actually happen properly. There are a large number of places in WordPress where the locale is compared to en_US and if it matches, then certain code is skipped or handled differently.
By and large, the en_US locale is a special case in WordPress and so any change that affected that would be a very big project indeed.
This is a tricky one. The gettext structure needs to regard everything that has to be translated as being from one and the same language all over a page. Core uses en_US, so programmatically per definition, the source language is always en_US, regardless of which language it's actually written in.
Perhaps a nice feature would be a batch program that might take your it_IT plugin and a po-file it_IT---en_US and quickly: