Welcome to WebmasterWorld Guest from 18.104.22.168
Forum Moderators: ergophobe
The only reason I want to avoid i18n if possible is because it seems like when I look at the issues for most of the modules I use or want to use - i18n is always causing problems with those modules.
I hope I don't regret it. I wish I could help. sorry.
I'd be interested in any lessons learned from the community of users here, and will be happy to share our experiences as we go through a similar process.
He discusses the locale module, content translation module and the localization server module (a new one on me - [drupal.org...] But he doesn't specifically address the i18n module versus locale.
Probably the place to ask the question is in the drupal group devoted to Internationalization: [groups.drupal.org...]
Also, you may be pleased to see that it looks like they're really working on these issues for D7: [groups.drupal.org...]
I now have my site in EN, IT and ES versions and couldn't be happier: the amount of sleep I've saved myself not pulling my hair out with trying to translate everything with i18n/Localizer...especially menu items, edit screens, images, etc.
It's a "non-solution" that has solved all my problems.
I used to be in daily contact with the developer of the localizer module and I quickly got the site 97% translated off on db, but then hit enormous problems and the guy himself admitted "yeah, you can't really do that - it'll have to be in english only". In the end, the code was hacked to pieces and I realised the only solution was to separate the sites.
the negatives are there, for sure. When I update drupal versions, I have to do three of them but that's basically an hour's work.
Anyway, I do the same - one code base for all sites, using the multi-site functionality, and then a separate DB for each site. I've seen mention of a multi-site manager that allows you to update them all in one go, but it's based on drush ("drupal shell") and it requires complete control of your dedicated server, which I don't have.
For each page, create two nodes (in my case I only need French on the canadian section /ca/ of our site) -
Then you could create a French template that runs everything /ca/fr*. And when you enter the node content you'd just enter it all in French.
You wouldn't need to run multiple core installs and I can't think of a downside?
I've honestly only used multi-site for completely separate domains, but certainly you're right, once drupal is running on the root domain, you can't run a separate install (same codebase, different DB) on a subdir. Or at least not easily because by default drupal will interecept everything at example.com/*.
So you would need to have a rewrite that tells the example.com/ site *not* to rewrite example.com/ca/fr requests to example.com/index.php?q=blahbbbbbaaaaalh
Well I guess I'm confused on how I get drupal to run at both example.com/ and example.com/ca/fr
Actually we're now consulting with a guy whose really good at Drupal and we're going to go with two installs of Drupal. One at example.com (english only with no multi-language features) and one install at example.com/ca/ (multi-language) which will end up with URLs of example.com/ca/en/ and example.com/ca/fr/.
I don't know why I was confused on the issue. Just create the /ca/ folder and drop Drupal in there. Two backends is gonna kind of suck but that's actually what our current CMS has.
So far, no fancy tricks will be needed at all. Just using Locale and Content Translation from core!
[edited by: BradleyT at 7:42 pm (utc) on June 26, 2009]
A man is walking along with the Devil and they are watching sage who is walking and stooping and picking something up. The man asks the Devil what the sage is picking up.
"Pieces of the truth," the Devil says.
"Oh, that's bad news for you" the man replies.
"No, not really," says the Devil. "I plan to let him organize it."
Sorry... feeling tired and whimsical. Glad you found what you were looking for.