The site that I am working on is bilingual, specifically in english and in spanish. This presents complications for any site of course, so this is a good trick to have in your arsenal. This is especially good for Drupal but will work on any site.
This will allow the particular selector to be used only when the language is set to spanish. Please note that many other languages can be used by this by replacing the two letter language code with the one that you need. EI – de for german.
I have a front/login page that is available to anonymous users. I need to be able to deliver the page bilingually but I rely primarily on the Drupal account settings and language switcher to determine whether the site is presented in English or Spanish. So how do I present in Spanish to anonymous users when appropriate? Drupal also allows you to use the user’s browser settings as well to determine what language to display. And it also allows you to change the order of factors to determine what language to present in. After some testing and a lot of thought about the UX, I have settled on,
- Browser settings – Helps for Anonymous
- Session parameter – If a Spanish defined account want to use the language switcher to get English instead for that session
- Account settings – The catch-all
- Default site language
In my specific case, this will provide the most flexibility for my audience.
I’m putting the finishing touches on my site and one of the things I have to do is translate a few stragglers on the UI. I use Bing Translator (see THIS for info about how to integrate this widget in Drupal 7) for translating externally generated content but since machine translation can be dicey, I try to translate as much as I can manually using Locale, Content Translation and other Drupal multilingual modules along with Selection Rules that look to the user’s profiled language. That way I can be sure the the UI itself is correct.
The Translate Interface feature from Drupal makes it pretty easy to track down strings that have or need to be translated. But because of its modular nature, this isn’t consistent. For example, I have a content type called HTML Text that I user to insert, HTML, of course. This works like an object in OOP languages, the HTML (it can form a link, reference an image, just about anything) becomes a node and can be placed anywhere on your site that you need.
In this case I have an image and a link that point to a relative path on the site. The text for the link itself is in English and I need it to be in Spanish as well. But since this is one of the cases where you can’t use the Translate Interface UI (because it is a custom content type) I have to acheive this by creating a separate node with the same text in Spanish. Two nodes, one location. In this case the placement is done via a minipanel that will be nested inside a larger panel. So, in the minipanel, I “stack” the two minipanels as seen in the SS. You can see that I use a Selector Rule to choose this Panel if the site langauge is Spanish. You don’t see it but the top panel has the same rule for English. The language is set on the user object of the account. Since these are separate nodes, they have separate node IDs within the CSS. So be
aware of how you implement CSS if the two nodes don’t style consistently.
Drupal has many quirks but I haven’t found one yet that can’t be worked around with a little creativity. This is certainly one such instance.
I have the module installed, the content type created and I have links that are made from this type. And the site opens in the iframe but the translator settings are not following the iframe, which is what I need. I need to be able to allow my users an easy way to translate external content. I’ll figure it out. But that’s about all I am going to be doing today.
I have a bunch of external links that I need to be displayed in a way that they still are a part of the site. This way, the external sites can still be translated from the translation widget that I have installed on the site. I have downloaded this module – External Iframes – and will be testing it out to see how it goes.
I went with a module based solution because I don’t want to write the code myself for doing I frames. I don’t want to have to maintain that.
X modulesX multilingualX bilingualX englishX spanishX microsoft translatorX iframeX external content translation
I am so happy right now that I could almost cry. If it weren’t for the mainliners that live in the halfway house that we share I would. You just don’t cry in front of felons…
I have the multilingual stuff setup just the way that I want. And it works really seemlessly. I have a variant (actually I have three) on the main page of my site, DOCResource.org. You can go and check this out for yourself if you want.
Variants – in this order – order is important!
- Spanish users – the condition on this is whether the site language is spanish or not. this variant has a panel pane that displays the Misc item created by the Widget mod that holds the HTML & Jscript for the language switcher. The variable on this page is controlled by one of two elements; the user account or the choice from the language switcher dropdown. All Drupal translated items are in Spanish via Internationalization and the RSS items are in English because that is the way they come in. If the user wants to see anything in English translated to Spanish, they can click the MS Translator Widget button in the top right.
- Authenticated Users – Shows the page the way it is for a default English speaking user. No Panel display for the MS T. Widget. This is the way a user would come in from the Facebook login as well. But, anyone can hit the dropdown switcher and get the same experience that someone will get from having an account that specifies spanish.
- Anonymous – Shows the login block and a limited version of the RSS Feed via a cloned view from the original. That way it updates the same way but the links are not enabled and the user is encouraged to sign in to the site to get more content.
This is great! Now what I have to do is place that MS T Widget on the pages that aggregator outside content (via RSS and email) so that a spanish speaker can read them natively. VERY VERY NICE!
This is so cool. I found what I have been looking for. The MS Translator Widget. It is free and can easily be integrated into a Drupal site via the Widgets module. This isn’t quite how I am going to use it but here are before and after screen shots from my front page. The first is the site as a spanish speaker would see it after login. You can see that it is already in spanish except for the content in the middle. these are the RSS feed stories that come in all the time. At the top right you can see the widget for the MS translator. I was able to get this up and running in no time at all using the widgets module.
I’ll post tomorrow how i configed the widgets module.
This is what it look like after I translate the page via the widget. All of the spanish text is left alone (except for the language drop down “Languages”… not sure will have to check but I think I know…) but the english teasers of the RSS stories are now translated. My spanish is good enough for me to be able to tell that the translation is pretty good. and free. There are some additional options for the widget that include auto translation, transparent to the user, and others. auto translation is generally not embraced because machine translation is generally about 70% correct. But, by translating the interface through the Drupal tools and using this widget, I believe that I can deliver a true multilingual site. and that is very cool.
I am basically done translating the interface into spanish from english. and it really was much easier than I expected. i used babelfish.com to help me with the translations that i had to do manually. the user can get spanish from the start if the account is setup that way or they can choose spanish or english from the language switcher drop down.
This is actually turning out better than I expected. And one of the things that I have discovered is that the Translate Interface interface (as seen below) is the key. But also, that you don’t have to have everything listed here translated for most sites. For example, i have found that about 33% of my Views being translated, as it shows here, is actually about right for my site. Much of what isn’t translated are system areas that my members will never see.
So, go through the interface from the perspective of the alt language user and find the text strings that need to be changed, do a Find on them in the interface, and then change them. Much will be case by case. But be flexible; you may decide to change more than you need at the time so that the future stuff will already be in place.
You don’t need Profile 2 for this. You can add a field to the form from Core.
I added this to the Manage Fields from here:
Home » Administration » Configuration » People » Account settings
This gives the user a drop down choice with the two languages. With English as the default. This does not affect the language that is chosen when the account is enabled but at least you know what they want.