Having a multilingual website is a must for my customers.
Plugins like WPML are damaging my customers’ performance, let alone their security.
Did you know that WPML is a stand-alone CMS? I have found out about it last week(!), therefore any plugin that is an overkill on my website’s performance has no place inside my platform.
Read-only archive: Issues · ClassicPress/ClassicPress · GitHub
Author: stefanos82
Vote count: 6
Status: Declined
Comments
A multilingual site is not just about translation.
It might involve the site reacting to browser’s locale, it might mean that under the hood is a multisite or even separate sites.
What localization plugins are very good at doing, is managing all these various options.
That is why they are complex.
It is true that a multilingual solution can be implemented in core, but given the various ways localization can be achieved on a multisite, it is better having a plugin handling it imho.
The opening comment is invalid.
WPML is obviously not a standalone CMS. It’s a plugin made for WP.
It doesn’t make a CMS to just put it in the plugin name, and it’s also not insecure or slow.
I know there have been massive hiccups some years ago (I used to work at the company) but these issues have been ironed out. The team used modern development approaches, has proper issue management and a huge capital and work force behind it.
As a matter of facts WPML is the industry standard since it’s out there for localized WP websites.
And, it’s even still compatible with WP 4.9
(WPML's Minimum Requirements)
That said, localization is already in core for several aspects, and that’s why I wouldn’t say it’s totally out of scope to also add custom localization such as post translation and else things to core.
I wouldn’t dismiss this idea fully.
I also believe this idea was discussed in other petitions already - at least one was the relationship petition that could open the ground to this feature too.
despite being a “standard”, its the most horrible choice. as soon as you get into more intense work, it fails HARD. with “intense work” we mean a site with about 4000 - 5000 pages PER LANGUAGE.
Its not their fault per se, because one cannot easily just drop backwards compatiblity and everything, but the code itself is pure dungeons of doom nightmarish.
Whats worked best so far is PolyLang. Its kind of the one plugin you just drop in, change a few settings, and it works rock-solid, no matter what you throw at it, whether it’d be small sites or batshit crazy ones with a multitude of plugins, WooCommerce in ultra-customized mode (including 2000+ products), and external API bindings. Their WooCommerce integration / add-on has been flawless so far, too.
There are obviously similar plugins like this, but PolyLang is the one out of the grabbag of 20 - 30ish ones that has been the one with the least complains - both from a developer and adminstrative / user point of view.
Other option is multisite (with or without MLP), but that has its downsides as well - not really recommended for smaller sites.
Guess I finally gotta do a write-up of all the options for i18n / l10n soon - this issue is coming up more and more, and everyone just blurts how fancy and cool WPML is (which it is decidedly NOT). Maybe as an interim thing to work on while I’m still preparing the WooCommerce fork 
cu, w0lf.
Is this actionable in any way?
It’s actionable in many ways. But as you already stated above, not everyone needs it.
This is plugin territory.
Core should be for things that are necessary, like an editor, a media gallery, apis to handle data, functions to tweak the admin area, hooks. From there on, Plugins should do the rest.
This is not in line with keeping the core light and clean, and multilingual support belongs in a plugin.
This topic was automatically closed after 2 days. New replies are no longer allowed.