Translatable content & localization at first installation

[discobot]

Translations is something blogger may not be interested to - indeed when talking about business you want translations to be easy.

When installing WordPress you’re asked for languages but this is just for the interface. Location shouldn’t be “optional”. It is something any CMS today consider at it first (eg ps, drupal etc…)

NOTES:

Translated content shouldn’t be a duplicate post (as done by wpml). This is stressful for database that will force to search related ids by language.

For example the “post_content” column should be in a pivot table that contains the language id. When doing “get_the_content” it will take the content per language and so on.

---

Read-only archive: Issues · ClassicPress/ClassicPress · GitHub

Author: Paolo Falomo

Vote count: 20

Status: open

Tags:

• difficulty-hard
• request-add-feature
• cp-research-plugin

---

Comments

This has got my vote for sure, translatable content should be a core feature and in theory a core-based implementation should be simpler than a plugin.

Translated content shouldn’t be a duplicate post (as done by wpml)

I’m not sure about this though. There is much more that needs to be translated than just the post content: post title, URL (slug + parent etc), other meta items, etc. Also don’t forget about categories, tags, and other taxonomies.

~ posted by James Nylen

I would still recommend starting this effort as a plugin if possible, that way we can iterate there and recommend the plugin for testing.

If you’d like to put something up on GitHub under the ClassicPress name, let me know and I’ll create a repository for it. ClassicPress/multilingual-content is one idea for the name.

In order to be considered for merge into ClassicPress core, the plugin should have excellent automated test coverage and consistent code style.

~ posted by James Nylen

I’ve marked Issues · ClassicPress/ClassicPress · GitHub as a duplicate because this one has more info. Copy/pasting the text of that petition here:

Multi-lingual support in WP has always been plugin territory (and probably should remain that way, to control core bloat). A few years back there was this project, led by Simon Wheatley, to give multi-lingual plugins (all bad/difficult implementations) some kind of core infrastructure, introducing a core language field, that would identify content language in the database (https://multilingualwp.wordpress.com/). It’s not an easy task, I know, but certainly this is an area where Classicpress could lead the way to a better multi-lingual content management. And a need for the enterprise market.

~ posted by James Nylen

N.B. We’ve created ClassicPress Research · GitHub for this purpose, so this repository would live there instead.

~ posted by James Nylen

I worked on that and I know a little bit how works.
Have different posts for languages is the best way to keep easily the compatibility because is more easy to alter wp_query in that way. Right now the multilanguage plugins do in that way to be transparent and this simplify as already said the media multilanguage and the set of custom post type.
The other point is how to define meta that need to be localized of settings like wpml/polylang did.

~ posted by Daniele Scasciafratte

I’ve been building business sites with WP for many years and ~9/10 sites are multilingual. I’m based in Sweden and have been working with companies in all Scandinavian countries + Finland and multilingual support is usually a base requirement from our clients when discussing a new website (no matter size of project). When talking about WP I understand the bloat issue, however if CP is taking an all business first approach it should be a core feature in my opinion.

Some other things to consider:

• Media: have the possibility to have localized meta fields for one attachment (e.g. one image => one “attachment” => language specific Alt text). In current translation plugins I think you’d have to translate the attachments, which is very time consuming and seems a bit unnecessary.
• Support for language specific settings (date and time output, reading options).

(Also, I believe Polylang Pro is far superior WPML).

~ posted by Erik

I will upvote anything that brings Multilingual more into Core - this is an area where WP totally fails as anything with languages, translations, multilingual was and is only an afterthought - and therefore got “hacked in” later on.

For example we need to be able to do a WP_Query by language.
Also it must be possible to set a language for any content type (post, page, etc.)

~ posted by David Decker

Hear, hear!

I’m with David and also Erik above on this.

Having worked the better part of my WP career in multilingual (WPML mostly), I think it is becoming an absolute necessity for this “feature” to be in core!

~ posted by Pieter Bos

Multilingual content should be absolutely in core please! There are almost no clients of me who did not need WPML on their sites.

I know it is quite complex, but let me just suggest consideration of the database structure as well. I mean DB structure of WP is just great for simple posts, but ultimately useless for custom post types. If a user just wants to have different posts types, then exactly that is what post categories are for.

Whenever i created a CPT for a client it was because the client wanted to have regular posts and some other type of content as well. As we all know right now all custom fields land in post_meta table which works of course, but is far from ideal. Personally i like a lot how is it done in drupal (the admin can define DB structure), so i would find a great idea to have GUI wizard for the creation CPTs and their DB-table. Sorry to mention it in this topic but it is has an impact how these CPTs can be translated.

~ posted by Peter B

I know it is quite complex, but let me just suggest consideration of the database structure as well.

Here, do you mean something like allowing the ability to split custom post types out into their own tables?

This is something that’s been discussed a couple of times in Slack, and alluded to on another petition:

for example, having all the posts and CPTs in a single table makes it difficult to restrict access by type, and unpicking this is not something to be undertaken lightly

I think this would be worth its own petition.

~ posted by James Nylen

Here, do you mean something like allowing the ability to split custom post types out into their own tables?

Yes, exactly. I made a new petition for that. Please feel free to edit the title if needed.

~ posted by Peter B

A good workaround or easier choice would be by adopting Bogo (which uses meta fields to handle everything - and that very slick) as a core plugin, and enhance it to use all Post and Taxonomy types.

Another step is creating a proper String Translation plugin, as next to all available ones are … at best of mediocre quality.
In next to ALL projects, that have required a String Translation table, we / I had to replace the given plugins (eg. WPML String Translation) with a custom implemention, either based on JSON or PHP arrays. I realize the idea behind String Translation is using gettext for everything, but both indexing and editing is tedious and finnicky, at best, and overloading and leading to fatal errors or the classic White Screen Of Death, at worst.

Having two core plugins, would be an intermediate step, so that there is at least something working in place. And after that, one could work on more massive, possibly backward compatiblity-breaking changes.

cu, w0lf.

~ posted by Fabian Wolf

As for me the best solution for multilanguage is Polylang – Wtyczka WordPress | WordPress.org Polska

I don’t know why Yankees are forcing WPML (overweighting database) instead of old tested .po files method with Polylang. For me each solution should be open to developers accurate to they custom experience…

~ posted by Dominiq

@Dominiq:
You are right about Polylang being a very robust and great solution.
WPML is a working and popular solution but from my experience one of the worst solutions out there, sadly.

But every plugin of this kind in WordPress world suffers from the point that they cannot truly make it a smart solution. Look at WPML’s numerous “Add-Ons” and integration plugins - they try to solve every little detail but it results in a big collection of “hacks”…

If ClassicPress is solving the “multingual issue” of the current WordPress in a future ClassicPress version this would be a major undertaking going at the core of the software and all its features. But in my opinion it has to be done some day.

As it can be seen with the business model and market appearance of WPML: this is clearly a core feature a business-focused CMS like ClassicPress needs. Without being truly multilingual ClassicPress would have a hard time in the long run.

As sooner as this whole topic gets solved once and for all this will be a HUGE advantage over current WordPress. Matt has said in the last days it will be a focus of WP not before 2020 - so if we get it solved earlier and better this will become a unique point for CP.

Not needing a “multilingual helper” plugin to solve a core issue is the way to go for CP in my opinion. Plugins in this space should extend/enhance what is there in core not adding the (missing) stuff itself.

~ posted by David Decker

Also lot of website needs just a bundle with direct one language, cause they don’t consider global range, want just make local site. Why would they have builded in this bundle WPML if they not consider multilanguage? For me - language bundles of WP is step forward before plugins downloaded with 30 not needed other language .po files. At start I got only en_US and pl_PL as i download polish bundle. If i make ML with polylang, then adding other language .po to components at they original language path. Also then can be sure WP (or CP) will read it.

Guys. Please just check Polylang and then tell me You really need WPML or CPML I shall said.

~ posted by Dominiq

I’ve used Polylang & codestyling localization plugin ( unexisted but old version still works) and it is compatible system with themes and plugins, easy to make ‘more custom’ existed translations for any amateur as all .po files are edited from wp-admin page. That solution could be at top instead of WPML that seems beeing created for premium plugins to people who doesn’t know what .po file are.

~ posted by Dominiq

So depend on my language settings browser shows me national subdomain pl.classicpress.net and there can download bundle with pl_PL and en_US as a minimalist version, optionaly can be link to MLbundle with all languages .po files, but that won’t be a minimalist package.

~ posted by Dominiq

Then developer can install WPML or Polylang or whatever else is on the market and not be framed to any translation system

~ posted by Dominiq

I’ve looked in wp-content/ languages and that’s 1,8mb just for WPadmin (744kb if just .mo files) count the weight of all translations if we had like 30 locales…

~ posted by Dominiq

Everybody interested in Multi Language task welcome to test this site i’ve made:

http://polylang.you2.pl/

Solid Solution For Multilanguage - Polylang + Codestyling L

Write me at slack to get login credentials. Merry Christmas!

~ posted by Dominiq