glueckpress/wordpress-post-language

[DISCONTINUED] Proposal for a new WordPress Core feature to determine and retrieve the language a post has been written in.

wordpress-post-language's Issues

Create plugin (summary)

Create a plugin implementing

• a filterable language selection in the Publish Post meta box
• a default set of languages to select from
• opt-in initiation of the plugin by add_filter( 'post_language', $locale ) where $locale would be the main language of the site that would also be the default language for posts set by the plugin
• a UI element for the previously mentioned opt-in initiation in Settings > General
• public template tags get_the_post_language() and the_post_language()
• public post_class() method for setting the lang and dir attributes on post elements

[Feature] Could we extend this with an auto-suggest per post?

Since we can do language detection based on the post_content with something like Google Translate API (https://cloud.google.com/translate/docs/detecting-language) or one of the other gazillion API's that are available nowadays? Would be neat.

Post languages as taxonomy

As an option we can store post languages as taxonomies. Following code add simple "Languages" taxonomy to posts.

    register_taxonomy( 'languages', 'post', array(
        'labels' => array( 'name' => 'Languages' ),
        'hierarchical' => false,
        'query_var' => 'languages',
        'rewrite' => true,
        'public' => true,
        'show_ui' => false,
        'show_admin_column' => true,
    ) );

Currently you can add languages dynamically, like categories. Possible to use wp_get_available_translations() and predefine languages.

Your feedback is very welcome!

Thanks for stopping by! There is a draft for a blog post in the README I would love your feedback on. The idea is to

1. create a Post Language feature as a plugin.

   1.1. Update: while we’re currently working with post meta fields on a plugin basis, the feature should eventually go into Core as a part of the WP_Post class. WP_Post is final, so we can’t extend it via a plugin; what we’re going to need (once we’re done with feature scope) is a patch for WP_Post. For further discussion regarding implementation into WP_Post please go here.

2. create a proposal for a new WordPress Core feature in Trac

3. create a blog post from the text currently stored in README

4. link from the Trac ticket to that blog post for context
   1.2. Update Contrib Day WCEU 2104: We might be doing one branch showing a meta-based implementation, and another one showing implementation with a taxonomy.

Please feel free to drop any of your thoughts, questions or ideas in the comments below.

Create base architecture

Create the basic plugin file and architecture. class Post_Language could be a starting point.

The default frontend English phrases.

I find it strange when changing to another language pack that the frontend default English phrases do not change. For instance: reply, comment, search etc.
These are typical WordPress phrases that should change along with the backend when changing WordPress language.

New property for WP_Post?

Ultimately, this plugin aims to be integrated into WordPress Core.

The most proper way I can think of how a Post Language feature should be implemented was to add a new property post_language to WP_Post.

But obviously that’s not possible for a plugin. How would we deal with that?

Default languages and text-directions – where from?

The assignment of a Post Language would rely on a set of default languages made available as a selection in the back-end UI. Question is: where would those default languages be defined in the first place?

1. Available core language packs

The plugin checks for installed core language files in WP_CONTENT_DIR . '/languages' and generates an associative array from those.
Benefits: An easy source to build from which opens up all sorts of possible relations, i.e. to $locale and WPLANG.
Caveats: There is no logically consistent relation between the language a post is written in and the main language used for a site’s front-end. A site with an English front-end may contain posts in French, Spanish or Chinese. Handing the control of content linguistics over to the user is somewhat the key point of the entire feature, so making installed language packs a prerequisite for using the feature would really add an inconsistent layer of complexity. In addition, text-direction values would still have to assigned to available languages.

2. A filterable language object

The plugin introduces a filterable language object which contains the following pieces of information for each language (example: British English):

property	value
language name:	English (GB)
iso code (short):	en
iso code (long):	en-GB
locale:	en_GB
text-direction:	ltr (default)

Benefits: Possibly @toscho has already laid the ground work here with the languages schema in Multilingual Press?
Caveats: Any, besides a ton of work?

Feeback?

Update:

3. A custom taxonomy

No idea why I hadn’t thought about it before, but as @mor10 explains it sounds pretty obvious languages should/could be hierarchal.

A custom taxonomy of languages would make a standardized solution regarding implementation and UI. It should also be sufficient regarding performance.

Pure Metadata or further consequences?

I've just been wondering and wanted to clarify - we are talking about solely adding a meta-information to a post, right? No further consequences that arise from that, right?

I ask because what about the interface? Will e.g. the way dates are displayed change? Or is the locale the page (think about a url) has totally independent from the language the content (think about post-content) has? Do e.g. sidebars stay EN when having DE content? Or does it switch according to the content? What happens on archive pages that have mixed-language content?

Mixed:

<html lang="en-US">
  <body>
    <article lang="de-DE"></article>
  </body>
</html>

Or content forcing the whole page to switch:

<html lang="de-DE">
  <body>
    <article></article>
  </body>
</html>