Multiple languages for SP

How many people have done multi-lingual sites in SP when integrating with a translations utility ?

I am curious on the approaches used.

Since tools have to be able to parse the date (usually can do .html or .xml), a SP approach would require either using DCRs or a translation preprocessor that can read .page files.

The DCR approach is standard and easy, but users would hate it. Why bother with SP when you are using DCRs for every freaking page on the site ? During the sales process, the users all saw the sexy drag and drop SP interface, using DCRs would not be popular.

So I am left with a preprocessor approach for the .page. For grins I sent a translations company a .page and their reply was: WTF is that ?

Are there other approaches ?

Find more posts tagged with

Comments

mlerman

Trying to handle multi-lingual sites within SP can be tricky. You need to separate out where the translating occurs from the layout/design, in order to get this to work.

Our site ended up going the DCR route, because we had additional requirements around data entry and significant business logic required around the data being entered (we use DataDeploy -> Java Web App -> Java Externals -> components to serve up most of our data); the users, currently, do not have the ability to WYSIWYG edit, however.

We (I'm chatting with my partner in crime here) would say you need a way to separate out the data. We're assuming you're going to have separate .page files for each language/locale you're working with. Assuming you have some kind of common naming scheme (e.g. page files have the same name and directory layout, just within a different top-level directory), you'll want to have some perl magic to:
- extract the necessary datums from your "source" .page files (and components)
- take a formatted file, send it over to translation
- perl can then go through your received translations and re-populate one of the other .page files

This process can be automated using workflow so it's less ad-hoc and more usable by power-business users without dev effort. e.g. your page file deployment kicks off a workflow with a user task that waits on translation, and only once the translation's in do you deploy the new .page files for all relevant languages. e.g. Deploy Page File
1) start
2) perl creates translation file
3) user task to view this file (or it gets emailed out)
4) user task creates a cgi screen to upload the file back in
5) perl drives the translation back into other pages files
6) push your .page's

This way, the users can WYSIWYG edit your page files for any language/locale, and you've developed a process to get the translations and manipulate the content separate from your presentation layer.

It's a good topic for discussion Smiley Happy

Crsb

5) perl drives the translation back into other pages files

are those pages pre-created with "place holders" and you just fill replace the place holders with data after the translation? or You actually generate them using perl after the translation is approved?

tec_iwov

a simple and static approach that customers use is to place internationalized content into DCR's. with the DCR Datum the locale will be used to retrieve the DCR. it will first look for full locale LL_CC then look for Language LL. then use the default. file naming convention is filename_LL[_CC].xml and filename.xml for the default.

nipper

a simple and static approach that customers use is to place internationalized content into DCR's. with the DCR Datum the locale will be used to retrieve the DCR. it will first look for full locale LL_CC then look for Language LL. then use the default. file naming convention is filename_LL[_CC].xml and filename.xml for the default.

Yea but then why bother using SP if everything is in DCRs ? The reason that people are buying SP/LS is the drag and drop WYSIWYG interface. My customer is quite unhappy because they were given a DCR based SP implementation. My choices are to either use straight DCRs or to figure out how to get .page files translated.

karel

Already implemented several multilingual websites in SP/LS, mostly DCR based.
Including java-based import/export mechanism for translation agencies.

For an SP/LS only version multilingual websites, maybe you can use/abuse Targeting?

mlerman

are those pages pre-created with "place holders" and you just fill replace the place holders with data after the translation? or You actually generate them using perl after the translation is approved?

You'd want them to be already created; this way, you have different .page files which you can modify, if your business users require a different presentation/layout for different languages.

tec_iwov

using DCRs for internationalization is not a negative and also does not defeat the use of SP. just like internationalizing of other web based apps the translated data is isolated from display. if your using java you use Message Resource bundles. this way you can hand off your data to possibly a third party and they don't need to be concerned with look and feel. Granted there are L&F aspects to internationalization but in most case you can get a lot accomplished with internationalizing the data.

ISCBorisB

If your using java you use Message Resource bundles...

That's a very interesting "if". How exactly can I use Java with the LiveSite? We use (sub)Classes of Java PropertyBundle
Class to do all our internationalization. One of the reason we've shunned LiveSite so far is that OTB we can generate only
*.html or *.page for the run-time.

At some point we've briefly considered using Site Publisher without run-time to generate Java/JSPs but decided against it.
We do exactly that from traditional DCRs anyway and conversion efforts without benefits of the LiveSite run-time environment
seems absolutely pointless. Or, citing Andy "why bother using SP if everything is in DCRs?"

Granted there are L&F aspects to internationalization but in most case you can get a lot accomplished with internationalizing the data.

To be sure, you'll get a lot of internationalization if you internationalize - whatever that means. Thanks.
If I can not use Properties, what to translate though and how? Populated Datums? .page Files? Something else?

nipper

using DCRs for internationalization is not a negative and also does not defeat the use of SP.

My customers would beg to differ. They bought TS/LS/SP because they wanted the drag and drop component interface. If that means add a component and then add a DCR to feed data to the componen, the customer will likely not be happy. They threw out one consulting company because that was what they delivered and the users revolted.

I wish Sunil was reading Devnet, because this is a serious issue. The sales team are selling one method and then, oh by the way, if you want to support multiple languages, use DCRS.

nipper

Or, citing Andy "why bother using SP if everything is in DCRs?If I can not use Properties, what to translate though and how? Populated Datums? .page Files? Something else?

I am hoping I can get the .page files and work with the translation company to teach them to read the Datum and translate that.

Crsb

The sales team are selling one method and then, oh by the way, if you want to support multiple languages, use DCRS.

I second that.

Rob76

a simple and static approach that customers use is to place internationalized content into DCR's. with the DCR Datum the locale will be used to retrieve the DCR. it will first look for full locale LL_CC then look for Language LL. then use the default. file naming convention is filename_LL[_CC].xml and filename.xml for the default.

Using this OOTB approach, all DCRs for X number of languages would be saved to the same folder under "data"? If so, is there a way to update a config file to look at a language folder (en,es,fr,etc.) instead of naming the DCR by the locale?

nipper

Using this OOTB approach, all DCRs for X number of languages would be saved to the same folder under "data"? If so, is there a way to update a config file to look at a language folder (en,es,fr,etc.) instead of naming the DCR by the locale?

I assume that there is but I never tried to implement it. The customer did not mind reading the locale, so we left that.

Shwe01

Already implemented several multilingual websites in SP/LS, mostly DCR based.
Including java-based import/export mechanism for translation agencies.

For an SP/LS only version multilingual websites, maybe you can use/abuse Targeting?

Can you explain me the DCR implementation in more detail...
I have a base dcr named "base" and some dcr's with names base_fr_be and base_fr and base_nl_be. how will LSCS runtime will fetch dcr checking the locale of the browser.Do we need to do any settings

Rob76

Can you explain me the DCR implementation in more detail...
I have a base dcr named "base" and some dcr's with names base_fr_be and base_fr and base_nl_be. how will LSCS runtime will fetch dcr checking the locale of the browser.Do we need to do any settings

The DCRs have to live in the same folder, they have to contain the locale suffix, and they need to be saved with .xml.

nameOfDCR_en-GB.xml

See the section "Create Locale Based Content using DCRs" in the SP Dev Guide for more info

Deployed.GIF

Ashish_Sangal

i did the same thing but it still fetch the base DCR content

Rob76

i did the same thing but it still fetch the base DCR content

Sorry, typo, should be "nameOfDCR_en_GB.xml". This is for the locale, if just language then all you need is "nameOfDCR_de.xml"

There are 2 formats:

_language.xml or _language_country.xml

However, having LiveSite automatically do this for you may go against best practice for SEO. Refer to your SEO requirements and best practices before implementing this.