Different approach to multilanguage

  • After having reviewed the few plugin solutions to make WP multilanguage, I found that WPML looked like the more thoroughly designed one, but even being the “less bad” solution, there are cases where it simply doesn’t fit. A photoblog for example.

    That is because it requires a different post (let alone the taxonomy) for each language, for which the images must be uploaded and set with specific captions.
    The routing logic is a weak point in WP (when compared to CMS solutions), and multilanguage implementations all but stress that week point very close to failure.

    What if instead (I am still just day dreaming here, and I admit it doesn’t look elegant), a multilanguage implementation were based on a single added DB table that incapsulates all translations (for posts, pages, images.. which all refer to the posts DB table, AND for taxonomy), which would be retrieved according to request, maintaining the original data architecture at it’s base.

    With a little hacking on the admin side, people could click “add translation” for each content (be it taxonomy, a post, a page, an attachment), while the DB architecture would remain totally clean. No inside-content-flags that would reveal multiple language content on failure. No duplicate DB entries that would cripple a large site editor when deactivating the plugin.

    On-off. When it’s off, the translations simply sit there, silent. WP works just as it did before the plugin was installed.

    I’m going to look into this in the next few days.. the hard part (I can already imagine) is hacking the image management (and maybe the categories).

    If any of you has comments, feelings and suggestions, please be my guest.. this is not my fulltime job anymore, so I might be easily overlooking something really stupid here.

Viewing 4 replies - 1 through 4 (of 4 total)
  • Thread Starter acolonna

    (@acolonna)

    One quick thought that came to my mind (and after this I’m heading for my pillow): routing.

    The cheap solution would be to keep it at it’s minimum: whatever WP is doing before the plugin is installed. This would mean, if English is the default language, that URL’s would use English terms and titles (assuming you are using permalinks, because there is no other way really, if you want your site to look professional) all the time, even when a user is accessing the website in French for instance.

    This shouldn’t offend anyone, because let’s face it, everyone knows English (at least enough to make out the meaning of the URL they are clicking to access that deep page of your site), and still it would be only appearling in the actual URL: the link would show the translated text as it’s content.

    Another solution would be to hack the routing logic, so to add something like aliases for your translated posts: based on the language the System has decided to work with (given for example the URL had a language prefix), it would match the URL parts against translated slugs.

    From the outside it would be like visiting a WPML website.. but from the inside your data architecture is nice and clean!

    I gave up on multilanguage blogging after realising most SEO plugins Tilt with the most slight mention to it.

    Sure, you can do some hacks and install a plugin for a plugin (inb4 I installed a plugin in your plugin, so that…), but that is not the most stable solution on a site who relies on it.

    Thread Starter acolonna

    (@acolonna)

    Well I’m starting off on a production site, based on WP (yess I am that reckless…) which I am currently learning.

    I figured that *maybe* for SEO, a good idea could be forcing the language ISO code into the URL, leaving all the rest the same between languages.

    I am currently in the process of hacking into the WP routing, using qTranslate as close reference. I think I already got all I could out of it, now I have to start fixing it’s issues (pre-path mode doesn’t work in some cases, for example https://domain.com/en
    it looks like it needs a trailing slash).

    One major issue I found is getting the path prefix to be injected in option calls (like get_option(“home”)), which are often used to build static menus and other bits of the theme.
    The same options are read by the plugin itself, so they require to be virgin (also because tapping into them results in an infinite loop).

    Once that is done, the rest should be fairly easy (a little DB and Admin forms…).
    Probably I’m missing something here… but I’m sure I’ll notice it when I bash my head into it!!!

    Thread Starter acolonna

    (@acolonna)

    I have completed step one: I now have a working routing plugin (still has to go through some more testing).

    The logic is very simple: given a set of enabled languages, the plugin looks for a language definition in the path (prefix).

    If none are found, it determins what language to use (first it looks for a cookie, then it looks for a session var and finally it goes through the request headers… if no other method works it just uses the site default language).
    It then redirects the client (301 Permanently moved) to the full path: this way we are sure clients are always exposed to an explicit language request in the URL.

    If a language prefix is found in the URL, it removes it for WordPress to do it’s magic and saves language information in a global variable.

    The plugin simply ignores everything related to ADMIN pages and system paths (using the bloginfo() function will produce full paths with language codes unless the paths point to wp-login, wp-admin, wp-content or wp-includes).

    I am deliberately ignoring RSS and other functionalities, because my production site does not make use of them.

    Now if this thing works correctly (it looks like it does, and it is perfectly unpluggable), the next step should be downhill: adding forms to the ADMIN section.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Different approach to multilanguage’ is closed to new replies.