Core i18n/Multilingual

Home Forums Community Summit Discussion Topics Core i18n/Multilingual

Tagged: ,

  • This topic has 14 replies, 9 voices, and was last updated 9 years, 5 months ago by Anonymous User 7658014.
Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • #654059
    Andrew Nacin
    Participant

    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/

    #654101
    Alex Frison
    Participant

    Hey 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

    #654106
    Anonymous User 7658014
    Inactive

    Though 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.

    #654172
    Ryan McCue
    Participant

    +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.

    #654197
    Japh
    Participant

    +1 🙂

    #654371
    Hristo Pandjarov
    Participant

    Core 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

    #654473
    John Blackbourn
    Participant

    +1

    #654572
    Alex Frison
    Participant

    Maybe let’s meet for lunch or in another break, all together and let’s talk about it. What do you think?

    #660501
    Petya Raykovska
    Participant

    +1

    #660511
    Benny
    Participant

    I 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.
    #660526
    Alex Frison
    Participant

    @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-language

    Then 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

    #660543
    Benny
    Participant

    Alex, 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.

    #660632
    Anonymous User 7658014
    Inactive

    I 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.

    #660642
    Benny
    Participant

    for 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, …?

    #660725
    Anonymous User 7658014
    Inactive

    These 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.
Viewing 15 posts - 1 through 15 (of 15 total)
  • The forum ‘Community Summit Discussion Topics’ is closed to new topics and replies.

October 25-26, 2014