Home › Forums › Community Summit Discussion Topics › Core i18n/Multilingual
- This topic has 14 replies, 9 voices, and was last updated 9 years, 5 months ago by Anonymous User 7658014.
-
AuthorPosts
-
October 21, 2014 at 7:33 am #654059Andrew NacinParticipant
We have a ways to go before we’re happy with the direction of i18n, but we’ve been firing on all cylinders for a few releases now. What’s next? And what steps can we take to either reach multilingual WordPress, or have a solid foundation for which a canonical plugin of some sort can reasonably implement it?
2012 discussion: https://make.wordpress.org/summit/2012/10/31/multi-language-plugins/
October 21, 2014 at 11:27 am #654101Alex FrisonParticipantHey Andrew,
we built a solution which is based on multsite and supports the core functionality of WordPress. Without restrictions or performance issues, other solutions may have: https://wordpress.org/plugins/multilingual-press/
Simon Wheatley and his team are already using our solution for some of their projects. We talked with him and his team about it in Sofia.
If you want I can show you at WordCamp SF a clean solution to make multilingual easy in WordPress, if you have five minutes. That would be really great! Maybe we can also have a panel discussion at WordCamp this weekend with people who are interested. What do you think?
Cheers!
Alex
October 21, 2014 at 11:33 am #654106Anonymous User 7658014InactiveThough I’m not going to be there in SF, I’d like to invite you guys to visit the Post Language repo for discussion and collaboration. Currently active developers are Silvan Hagen, Ryan Hellyer and George Mamadashvili, and we’d totally love your feedback and (hopefully) pull requests. 🙂
Gist of the project: implement a post language API (based on a custom taxonomy) as an opt-in feature that would offer a standardized method for plugins to build multilingual functionality upon.October 21, 2014 at 1:40 pm #654172Ryan McCueParticipant+1
This is something we’re also talking about with projects at Human Made, so I think both myself and Japh would be pretty interested in this.
October 21, 2014 at 2:41 pm #654197JaphParticipant+1 🙂
October 22, 2014 at 2:49 am #654371Hristo PandjarovParticipantCore multiligual support is something I’ve wanted since the day I installed WordPress for the first time. Definitelly an interesting topic with a lot of ground for discussion!
+1
October 22, 2014 at 9:38 am #654473John BlackbournParticipant+1
October 22, 2014 at 1:50 pm #654572Alex FrisonParticipantMaybe let’s meet for lunch or in another break, all together and let’s talk about it. What do you think?
October 27, 2014 at 6:10 am #660501Petya RaykovskaParticipant+1
October 27, 2014 at 6:55 am #660511BennyParticipantI would like WordPress to be natively be multilingual, with preferably these abilities:
1. neglectable (performance/storage) impact for non-multilingual sites
2. makes any plugin or theme – out of the box – multilingual ready as long as it adheres to current (WP 4.0) best practices regarding i18n.
3. can group posts as language alternatives (needed to quickly find post translations)
4. if no language is specified on a table row it applies to any language
5. back-end can be single-language while front-end is multilingual.
6. regardless of the language set for the back-end, the user can switch the edit-language to any of the supported front-end languages.
7. slugs are unique per language
8. promote as best practise: put admin (back-end) specific translations in separate translation files
The sought after solution would allow the developer for example to define an option, custom field or term to be language specific (default) or not.
Even if a theme or plugin wouldn’t be built to be multilingual ready it would still be.
The editing user would simply set the edit language (in admin bar) to the required language and WordPress would automatically retrieve/save the correct data based on the current editing language and the defined language specificness.Of course all relevant API functions and hooks would need to incorporate the language into their logic too. For example, this way when a non-multilingual prepared plugin retrieves an option value it would get a language specific value!
Many theme and plugin developers who only used to and familiar with single language sites don’t understand the need for and problems and needs of multilingual sites. This probably won’t change for the majority of them. They don’t want to put the extra effort in to finding out what’s needed and how to implement it. The ones that do are put off by the lack of a standard. With the above proposed solution they wouldn’t even have to! It would work out of the box!
—
Most other suggested solutions come down to the idea that translation is always on a post by post basis. This it to limiting. E.g. in an e-commerce system a product has a lot of attributes that may or may not be language specific, options may or may not be language specific, taxonomy terms may or may not be language specific. So in this case we don’t want the store owner to type over the same data in every language they support when this isn’t (shouldn’t) absolutely necessary.
The extra problem we had in the past with multisite based multilingual solutions is that, besides the above, a lot of third party plugins/themes don’t play well with multisite.
- This reply was modified 9 years, 5 months ago by Benny.
October 27, 2014 at 8:06 am #660526Alex FrisonParticipant@bvl, if we get this in core, as mentioned by caspar in a comment above:
http://glueckpress.com/5973/post-language-core/
https://github.com/glueckpress/wordpress-post-languageThen we don’t need multisite anymore to realize a clean solution with plugins.
As you see, to have this native in WordPress it is a huge effort to do so. There are so many things to take care of and consider, it will be massive.
Also, maybe only 10% – 20% if not less are using WordPress as Multisite. More than 50% using WordPress other than in English, but then only in their language, so this isn’t an issue for most of them neither.
Just my 2 cents.
Alex
October 27, 2014 at 8:48 am #660543BennyParticipantAlex, I feel the ‘Post Language’ feature is only suited for a limited number of use cases. It would be enough for a multilingual blog but not for a CMS with more complex post types. As said I would like to see a more flexible solution as explained in my initial comment above that would suite more complex cases like the described ecommerce/product one which has content parts that are language independent like e.g. the brand name taxonomy, weight, price, images,etc (custom fields), some options while other content parts are language dependent and require translation.
My suggested solution direction would allow your ‘Post Language’ feature, but would also take things (when desired) a step further by also making things like options, custom fields etc (optionally) language specific. All in such a way that it even would work when not planned for by the original (theme/plugin) developer.
October 27, 2014 at 3:11 pm #660632Anonymous User 7658014InactiveI feel the ‘Post Language’ feature is only suited for a limited number of use cases.
It is meant to become the most basic common ground for almost all use cases, before we even think of translation at all.
October 27, 2014 at 3:59 pm #660642BennyParticipantfor almost all use cases
By not forcing the user to set a particular language or, in other words, by allowing to set the (custom) post to be language neutral, it would become the basic common ground of <i>all<i> use cases I think, including the direction I am suggesting 😉
Why are you just looking to cover the most basic common ground; the ‘Post Language’?
What do you think about being able to set the language for things like custom fields, taxonomies/terms, options, …?
October 28, 2014 at 12:05 am #660725Anonymous User 7658014InactiveThese were my premises when I posted the (yet unofficial) Post Language proposal:
1. Multilingual content doesn’t necessarily have to be translated content. It can also be just unrelated content in different languages. The most basic metric WordPress should provide as a software would therefore be a language property for the post object, in order to standardize the data developers would work with to achieve all kinds of language-related functionality.
2. For translated content there are many and unpredictable cases of use and implementation. WordPress core should stay clear of the translation territory and leave it to plugins, only providing the basic API feature named above.
Since we’ve discussed a multilingual core solution in #polyglots, I’m actually beginning to see the approach above may have been somewhat naive. In a world of CMSs competing for market share it might not make sense from a marketing point of view to implement a solution that would leave pretty much all the work to plugin developers (which would be sort of the second greatest “feature” of the minimal approach described above), when you can just go ahead, build a full multi-language feature from the ground up, and go advertising WordPress then being fully multilingual by core.
I’m just afraid that approach could result in implementing one solution “to rule them all” short-sightedly—heck, we’re still talking about an edge case only very few of us have greater experience dealing with! 😉 Imho we can only hope it is going to work for all the languages and use cases out there.
However, this is all very vague, so I’m going to listen and watch you guys for a while. Maybe I’m all wrong and need to learn.
- This reply was modified 9 years, 5 months ago by Anonymous User 7658014.
-
AuthorPosts
- The forum ‘Community Summit Discussion Topics’ is closed to new topics and replies.