Thanks for the interest... Meanwhile, i implemented a new version that fixes a couple of bugs, but this is not yet ready for all, it's just a proof of concept for developers, and it still needs some work.
From the point of view of the user, the plugin adds in the post and page edit forms a field for each language activated in qTranslate, where you can manually specify a different slug for each language.
It generates links for posts and pages using the translated slug, but to switch to another language (for now) you have to embed in the theme one of the function defined by my plugin: qTranslateSlug_generateLanguageSelectCode($style, $id) or qTranslateSlug_getSelfUrl($lang).
From the point of view of the developer, it defines a table where you can store a different slug for each language, for each page and post (and hopefully in future also tags and categories):
- Code: Select all
'CREATE TABLE '.$wpdb->prefix.'qtranslate_slug (
qts_type TINYINT(3) UNSIGNED NOT NULL,
qts_id BIGINT(20) UNSIGNED NOT NULL,
qts_lang VARCHAR(6) NOT NULL,
qts_slug VARCHAR(200) NOT NULL,
PRIMARY KEY id_lang (qts_type, qts_id, qts_lang),
KEY post_name_lang (qts_slug, qts_type, qts_lang)
Then defines a filter for the wordpress request, and checks if the requested path is a translated slug for a page or post in the current language. If it can't find it, then it continues using the normal slug system.
It defines also the filters called when pages and posts links are generated, so when wordpress generates a link for a given post or page id, the link contains the translated slug.