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.
- The topic ‘Different approach to multilanguage’ is closed to new replies.