WPMU / WP3.0 multi-sites, public registration & qTranslate

[RavanH]

Hi,

Charmed by the relatively simple (no new DB tables, no endless configuration like WPML) but still powerful plugin that qTranslate is, I am considering to start using it for a public Multi-site setup I am currently developing. It will be WP3.0 with Networking (MULTISITE) enabled, allowing many people to start a simple blog/site. The network will be dedicated to a particular region in France so it will not be a global community. Still there will be need for translations since the area heavily depends on tourism. Hence my search for a good multi-language plugin.

Now here is the thing: after testing about all the language plugins around that seemed to offer what I am looking for, only two serious candidates remain. The two big ones: qTranslate and WPML. Now WPML is still not really ready for WP3.0 except when I would set the network up so that individual blog owners can activate it themselves. They would then have to start manage the settings and there is where I fear it will go wrong. Its just a bit too complicated for simple folk that just want a little website where they can present themselves in three different languages.

qTranslate is much easier in that respect and the back end does not invite people to go and mess it all up so much. Even though they still can... (!)

So what I am going to propose is basically a package of changes to make qTranslate truly ready for the "multi site + public registration" setup that will be available in WP3.0 as it has been in WPMU up till now. These suggestions are all with new blog owners in mind that do not know WordPress let alone even heard about qTranslate. Basically, the main thought is to make it as fool proof as possible even if that means locking some options to a fixed setting to prevent total site breakage:


I. SUPER ADMIN (GLOBAL) LANGUAGE SETTINGS

In WP3 there is a new concept: Super Admin and the Super Admin menu. This only comes available after activating the MULTISITE feature. Its something from WPMU and allows those that have complete network-wide admin rights (as opposed to those individual blog owners that only have site/blog-wide admin rights) to control major network settings.

Now in its current state, qTranslate (activated either network-wide or per blog) gives full configuration rights to the individual blog owner. This brings along some major problems:
1. A new blog owner cannot be expected to immediately grasp the qTranslate concept and when confronted with default settings that make no sense (english probably, german maybe but chinese is very unlikely to be ever used on a French blog) is likely to get so frustrated he/she will just abandon the whole site and both I and qTranslate Services will lose potential customers.
2. A setting like URL Modification Mode allowing for example Pre-Domain Mode (ex. http://en.yoursite.com) on a MULTISITE setup with SUBDOMAIN_INSTALL (formerly VHOST in WPMU) set to true, will break a new blog owners site when activated. The new blog owner will not understand what hit him/her and leave. Again we loose.
3. The automatic Update Gettext Databases feature might cause a conflict when it is activated from two different blogs at the same time and updates co-inside causing a server error and .mo file corruption. Just thinking out loud here and not sure about this but potentially NOT a nice thing....
4. Things like Convert Database simply cannot be allowed to be used by individual blog owners. Stuff like that might corrupt the complete database. This, obviously, we REALLY do not want happening on our network.

So what I propose is this: make qTranslate detect MULTISITE global value (maybe not even necessary?) and if found, create a second settings page for Super Admin only. On this page, Super Admin > Languages, the network admin should be able to set new default options (that apply to each new blog created in the future) AND determine either for individual options or for groups of options (example the complete Advanced section!) whether they can or cannot be modified on a blog/site level by each new blog owner.

This way a network admin can set qTranslate to be as fool-proof or user-friendly or feature-rich as he/she wants or thinks the target blog owners are capable of handling


II. AUTO-DETECT GLOBAL LANGUAGE VALUE

For instance, on the network I am setting up I want new blogs to have French as their main language. So I put

Code: Select all

define ('WPLANG', 'fr_FR');

in wp-config.php. But as soon as qTranslate is activated, the main language reverts to English making the complete back-end show in English. Now I know for a fact that this is likely to be a BIG problem for many of the local French folk that (like I said) are just looking for a simple way to get a small site up and running.

If qTranslate would auto detect the WPLANG global value and auto-enable the equivalent preconfigured language and make it default at the same time... that would be just so much more user friendly.


III. LANGUAGE CHOOSER WIDGET AUTO-ACTIVATION

Have the plugin insert the language widget in the main sidebar automatically as long as it is not done manually. Preferable controllable from the qTranslate options page during the first setup. If that is too difficult since it depends completely on the theme where the best place is for the Language switcher widget, simply activating it in the first sidebar found would be even better than nothing.

New wordpress user that are still learning about the WP settings cannot be expected to be aware of the fact they need to go and activate the Language switcher widget (if they even know what widgets are!) to get those flags flying on the front end... Unless of course qTranslate would display a admin message saying they need to go and check the language settings and activate the widget...


IV. TRANSLATE SERVICES AFFILIATE PROGRAM

One of the nicer features of the other language plugin, WPML, is the possibility to become an affiliate member of their translation service so that the network owner might get some revenue (30% in their case) from opening up a completely new and potentially large clientèle to their service.

You have to admit: its a nice teaser! If qTranslate where to have this too, I'd start with the plugin right away even if the first three suggestions have not been implemented despite the extra work having to personally configure qTranslate on each individual blog.

[RavanH]

V. GET (X)HTML5 READY

At the moment, qTranslate inserts some tags in the source head that do not comply with HTML5 specs. Passing a site running on WP3.0 using the default theme and qTranslate active through a HTML5 validator, results in these errors:

Error: Bad value fr_FR for attribute content on element meta: Bad variant subtag.
From line 19, column 1; to line 19, column 54
4565" />↩↩<meta http-equiv="Content-Language" content="fr_FR" />↩<styl
Syntax of language tag:
An RFC 4646 language tag consists of hyphen-separated ASCII-alphanumeric subtags. There is a primary tag identifying a natural language by its shortest ISO 639 language code (e.g. en for English) and zero or more additional subtags adding precision. The most common additional subtag type is a region subtag which most commonly is a two-letter ISO 3166 country code (e.g. GB for the United Kingdom). IANA maintains a registry of permissible subtags.

Warning: The Content-Language state is obsolete. Consider specifying the language on the root element instead.
From line 19, column 1; to line 19, column 54
4565" />↩↩<meta http-equiv="Content-Language" content="fr_FR" />↩<styl

Error: The rev attribute on the link element is obsolete. Use the rel attribute instead, with a term having the opposite meaning.
From line 29, column 1; to line 29, column 87
↩</style>↩<link hreflang="de" href="http://aufildudoux.fr/de/" rel="alternate" rev="alternate" />↩<link

Error: The rev attribute on the link element is obsolete. Use the rel attribute instead, with a term having the opposite meaning.
From line 30, column 1; to line 30, column 87
rnate" />↩<link hreflang="en" href="http://aufildudoux.fr/en/" rel="alternate" rev="alternate" />↩<link

Error: The rev attribute on the link element is obsolete. Use the rel attribute instead, with a term having the opposite meaning.
From line 31, column 1; to line 31, column 87
rnate" />↩<link hreflang="nl" href="http://aufildudoux.fr/nl/" rel="alternate" rev="alternate" />↩</hea

Technically, since the Content-Language meta tag is obsolete, it could be removed but since the majority of themes use XHTML 1.0 or HTML4, I suggest to make it use the same "lang=" value as is used in the html-tag. In the above example that would be:
<html dir="ltr" lang="fr-FR"> and <meta http-equiv="Content-Language" content="fr-FR" /> (notice the hyphen!)

About the REV tag error: it should just be removed. In HTML4 it is exactly the same as the REL tag. In XHTML it is supposed to be used for a "reverse moving link in a series" which does not apply here. Just the rel="alternate" and hreflang="nl" (and maybe a type="text/html") tag will do

[Person]

I.
1. Edit qTranslate.php yourself (See #II), and/or provide instructions to your own users. It's your responsibility to inform them how to use a certain plugin, especially if you're imposing it on them.
2. It shouldn't, it should simply create en.subdomain.domain.com. If this causes problems for your setup, remove the option.

II. If you want to fix the default languages available and their order, edit the following line in qTranslate.php:

Code: Select all

// enable the use of following languages (order=>language)
$q_config['enabled_languages'] = array(
      '0' => 'fr',
      '1' => 'en'
   );

// sets default language
$q_config['default_language'] = 'fr';


III. No widgets get automatically added to sidebars. If you absolutely want to see qTranslate included in the default theme setup, then edit your themes to include it. This is a WordPress limitation, not a qTranslate one. Your suggestion would also cause redundancy problems for those who choose to integrate the language switch option inside their themes.

[RavanH]

Hi Person, thanks for responding.

1. Edit qTranslate.php yourself (See #II), and/or provide instructions to your own users. It's your responsibility to inform them how to use a certain plugin, especially if you're imposing it on them.

Editing qTranslate.php is relatively easy, I know (and did) that. But it should be obvious what the downside of that is: Every upgrade will break these changes...

Please do not judge what I aim to do by calling it 'imposing' anything upon anybody. My objective is to provide some easy and cheap means of running their own (preferable multi-lingual) corner on the web for relatively unsavvy people that do not want to be bothered with complicated instructions before they can start typing what they have to tell the world. You have to appreciate not all bloggers are geeks that know (or care to know) the inner workings of WordPress, let alone some lesser known plugin.

2. It shouldn't, it should simply create en.subdomain.domain.com. If this causes problems for your setup, remove the option.[/code]

Well, you might not be familiar with how WPMU and WP3.0 in MULTISITE mode handle subdomains but believe me, it does create a problem. In this case en.subdomain.domain.com will be recognized by the system as a completely new site instead of a translation of subdomain.domain.com...

III. No widgets get automatically added to sidebars. If you absolutely want to see qTranslate included in the default theme setup, then edit your themes to include it. This is a WordPress limitation, not a qTranslate one. Your suggestion would also cause redundancy problems for those who choose to integrate the language switch option inside their themes.

Hmmm... Although I have seen other plugins that do this, I get your point about redundancy.

[ixta]

I agree with Ra, the potential is HUGE with qtrans working fluidly for the common end user.
Businesses and individuals do not know the gigantic market they are missing out by publishing a monolingual site.

[Qian Qin]

hmm... html5... i wonder if there is a way to detect what doctype is being used? :/ adding an option in the configuration is way too uncomfortable.

[bedex78]

@Person:

III. LANGUAGE CHOOSER WIDGET AUTO-ACTIVATION

I think what RavanH is trying to say in regards to auto-activation is to have a switcher function, ie. a function to call the switcher... so theme builders can have the switcher as a default feature in the design (out of the box), instead of asking the user to manually implement the widget. I certainly would love to have this feature in your plugin.

UPDATE:

I'm sorry... I didn't read the FAQ before posting... It seems that qTranslate does provide a switcher function. Check out the FAQ, under the topic "I don’t use Widgets, how do I get a Language Switcher?" (viewtopic.php?f=3&t=3&p=16#p16)

The function, just in case:

Code: Select all

<?php echo qtrans_generateLanguageSelectCode(); ?>

Cool! Thanks!