25 Comments

  1. zu

    Thanks for mention this proposed post language feature. I hope it’s getting some traction as the world is multilingual and WordPress should be too!

    Report

  2. Sky4git

    Recently discussing WordPress multilingual features in the developer meetup. Good to know WordPress is planning to include it in the core.

    Report

  3. Bartosz Arendt

    I hope this discussion will be continued.

    One of the major reasons why we started developing our own plugins was the fact that if we needed complex functionality working in a multilingual enviroment, there was no solution – more complex plugins (for events management, membership) were just not working with WPML or Polylang (which are definitely best multilingual plugins in my opinion).

    Providing a core Language API would allow developers to standarize at least some of the methods of handling multilingual content.

    Report

  4. Torsten

    This is so important for WordPress. Please help Caspar and make this happen!

    The language selection would return the ISO code for that language and store it in a database field as post meta or an extra field that would have to be added to the database table.

    Some languages (German for example) have the default translation *and* a formal translation, so please do not just use the ISO code. We should have a possibility/parameter to switch these different translations, too!

    Report

    • Caspar Hübinger

      @Torsten While I’ve felt the pain dealing with formal/informal translations, I don’t see that issue within the scope of a language-per-post feature at all. Formal/informal needs to be considered when installing language packs. Given the fact a switch between formal and informal within one and the same site would be an edge case at most (generally you’d pick one and stick with it for the whole site), I don’t see any case right now where bringing that switch to the level of authored content on a per-post basis would add relevant value to user experience in WordPress.

      Report

  5. Caspar Hübinger

    Thank you, Sarah, for covering the topic so thoroughly. Not much to add, but emphasizing again this needs more eyes to be looked upon by in order to make it happen. With all the great effort being put into 4.0 currently and positive feedback for the idea in general, I’m confident we’ll make it happen soon.

    Report

  6. Commentguerir

    I always appreciate the genius of the wordpress developer to add useful functions in the core. This new language option is very interesting, especially for sites that want to grow at the internationaal

    Report

  7. Christian Foellmann (@cFoellmann)

    I can’t wait for 4.0 to drop (for all the 4.0 goodness) and @glueckpress proposing this on Trac so we can make some noise for this. A big following there is an easy way to get some weight behind it.

    Report

  8. Marko Heijnen

    I don’t see this happening soon (1-2 years from now) because the statistics that are used to make this point aren’t the right ones. The post language selector only makes sense when you have a multilingual site and that percentage is not that high. That said the work done in 4.0 are a big step forward.

    I believe to make steps in adding better multilingual support we first need to work on the roadmap for taxonomies so at one point we do have native support for relationships. Also we should work on making the current multilingual plugins better and have user tests done to see what users like from all the plugins out there. They are quite different from each other but we could look if they share common code and try to integrate that in WordPress.

    Report

    • Manuel

      Regarding the statistics: When discussing a new feature, should we watch at the percent of users *already using* that feature through third-party implementations, or at the percent potentially benefiting from it?

      I don’t have numbers for the first part – stats of major multilanguage plugins may provide an estimate. Regarding the potential: even in the US, with just one official language*, about 20% of the population is multilingual. Not speaking even of China or India.

      *Edit: Wikipedia proves me wrong :)

      Report

    • Caspar Hübinger

      @Marko Heijnen

      The post language selector only makes sense when you have a multilingual site and that percentage is not that high.

      What @Manuel says, and: define “multilingual site”. ;) We usually think of translated content when we hear “multilingual”, don’t we? But that’s not the only use case for language-per-post. Matter of fact, that’s not the way we communicate as (mostly) bi- or multilingual human individuals. (I recommend Stepanie Booth’s talk from WordCamp Switzerland this year for excellent explanation of why confounding multi-/bilingual and translated content is such an unfortunate misconception.)

      To put it clearly: I cannot see any justification for a “multilingual” WordPress core feature that would cover or even touch the broad issue of translation of authored content. Language relationships (and thus translation) imo can and should remain plugin territory.

      Despite the title of this post showing the term “multilingual”, my proposal is not about bringing what we generally refer to as “multilingual functionality” to WordPress. The future feature or API we’re talking about imo should not cover relationships between languages.
      There are several ways of implementing language relationships for specific use cases none of which should be preferred or excluded from the pallet of possible solutions by default.

      Report

      • Marko Heijnen

        That is the only concept for me that makes sense. The general concepts are blog post in 1 language or having multiple languages and have one post translated to another language (not meaning always the same posts).
        So “language-per-post” targets the first. It targets the users who sometimes posts something in another language. Adding a selectbox in an area what is already crowded doesn’t make to much sense to me.

        Report

  9. RavanH

    I propose simply merging Polylang into core :)

    Report

  10. Andreas

    Sadly, I don’t see this being included in core anytime soon. Most core developers come from monolingual cultures and can’t understand people needing to make their sites available in multiple languages. So, we are stuck with plugins such as WPML (not free and bloated) or Polylang (free but lacking some options).

    Report

  11. softmodeling

    This is how Drupal does it (table node has a “language” column) and I agree it’s really useful, not only to know in which language the post is written but, more importantly (when having to manage/update the site), to know if the site is multilingual

    Report

  12. Sapan Shah

    This is very promising development. Looking forward to a day when WordPress site development & content addition in Hindi would involve a process of only downloading default WP setup, installing and voila! वर्डप्रेस हिंदी मैं :-)

    Report

  13. nicknielsen

    Contrary to what seems to be a kind of it hasn’t happened yet so it won’t happen consensus voiced here, I think reflection about language issues in WP is long overdue.
    Recent WP development has been all about the shiny bits – multimedia (still clunky), the fantastic things for theme developers… but nothing about what should be basic core functionality.
    Language attributes is a start, but I think there should be some sort of thinking about how (even if the nuts and bolts are done through a plugin) multilingual posts could/should be implemented.
    Almost all the plugins I’ve looked at or tried out have tags within the post that wrap the content for each language – I still use one developed by Jennifer Hodgson years ago that works this way – a language attribute would be useless in this case as the post contains both (or more) languages.
    With a language attribute metadata the logic would be a each language version of a post would be a post in itself (in the database) which would then be linked in some way (so that they could be retrieved for comparison and editing and selected at the front end).
    I don’t think you can introduce post_language() without thinking through to end of the process.
    But it is essential that it be done !

    Report

    • Caspar Hübinger

      I don’t think you can introduce post_language() without thinking through to end of the process.

      Agreed. Which is why this proposal needs to get the attention of our best software architects in order to evolve into an official proposal finally.

      Report

      • Bartosz Arendt

        Caspar, thanks for starting this discussion.

        I was thinking about the possible ways of implementation.

        If we needed a language attribute for posts only the ideal solution would be to add new “post_language” or just “language” column to posts DB table. Then extend the WP_Query with this new parameter and add a couple of post language related functions just like you did in your code. I think it would be the most natural way of handling that, keeping the relation between post and postmeta intact.

        In this logic, WordPress comment, term and user tables should also be extended with a “language” column.

        Unfortunatelly, that solution is impossible or at least not recommended to do in a plugin – it would require an involvment of the WP core team.

        My second idea idea is to create 2 new DB tables similar to terms and term_relationships, for eg. languages and language_relationships. Language would store the languages you have in your site, language_relationships would contain the relationships beetween objects (posts, comments, terms, users) and the language. There’s would be no need to extend existing tables here.

        Report

  14. Steve Bennett

    While ISO code may be helpful in the database, please don’t forget the SEO aspects of this conversation. Schema.org and IETF.org provide best practice information for displaying and tagging inLanguage, specifically:
    https://schema.org/inLanguage
    http://tools.ietf.org/html/bcp47

    Report

  15. Caspar Hübinger

    Late follow up on occasion of WordCamp Europe: I’ll probably be working with Silvan Hagen and others on the core feature proposal during Contributor Day on Monday, Sept 29th. Please feel free to join us in person or remote via Twitter, Hashtag #postlanguage. Thanks!

    Report

Comments are closed.

%d bloggers like this: