Thanks for posting this question - it'll be interesting to hear what the other opinions are.
In the past I've recommended starting with your approach -- one language. Over time, you can create new spaces or areas of the community for speakers of other langauges if there's enough demand for it. It's the same approach for adding new communities - start small and add them over time.
I was visiting a customer in the Canadian government who by law has to provide their services in English and French. One of their chief collaborators brought up the issue of language. Although this person was a strong English speaker and presenter, she said that her complete opinions and voice only come out in French. It was interesting to hear her opinion from such a proficient English speaker.
If you are interested Carl, I can pass along your contact info to my contact there.
I like the Nike idea of selecting your language Thanks! The only problem I see with our company is someone selecting their native language yet trying to collaborate with someone in another contry utillizing thier native language (like european spanish and english). Will the claerspace solution support the translation capabilities automatically for these instances?
I like the Nike idea of selecting your language Thanks! The only problem I see with our company is someone selecting their native language yet trying to collaborate with someone in another country utillizing thier native language (like european spanish and english). Will the claerspace solution support the translation capabilities automatically for these scenarios?
This is not to mention all the rich media content that is language specific, we would need to find a way to replace the content on the fly to support the language of choice.
If not we go back to a common language theme in which Carl mentioned earlier.
Interesting challenge. What to do???
Great discussion! In my experience as an IBMer - one of 350,000 worldwide employees - it was understood that the international business language was English. So, if you needed to collaborate internationally, everyone used English. Otherwise, use your native language. Trying to create an environment where everyone can understand everyone else, is, in my opinion, unrealistic. Unless everyone can speak "math". :)
Also, using machine translation servers to translate content has never really worked. They're good at translating the gist of the content, but not the nuances, colloquialisms, etc. Ain't nothing like a real human being doing the translation.
I've seen companies employ translators to translate critical content into supported languages, but everything else is left to grow organically.
I fully agree with you. The technology for doing this (especially on the fly) is not perfected.
Have you run into anyone that refused to standardize on a common language for their communities?
On another note we have found in places like Argentina that the people prefer to write than speak. They feel (and so do I) that there english is better written than spoken.
Good discussion and relevant for what "fun" i'll be dealing with in future, throwing my weight into this just for the heck of it.
"How are the rest of you handling this issue?"
In much the same way, "english" being the standard, however as a mainly social venture theres abit more flexibility for us, a "common curtosey" rule will be inplace, simply "While english is preferd, if those you are currently engaged with can -all- understand and communicate in an alternate language feel free until the situation changes".
"Is confining the community to English only a usage good idea?"
In a very wide and "fluid" community setting a "standard" is a very good idea, unfortunatly some may feel "left out" or worse "discriminated" against, however you cant "please" everybody.
The downsides to it are primarily exclusion, not just of people who cannot yet speak english who could bring needed talents or experience, but also of idea's, language its long been proposed "dictates" thought, people who do translating sometimes note that how they veiw something or conceive of an idea changes based only upon the "language gear" their mind is in.
"Should we allow international teams to create spaces for communicating in their native language?"
So long as you have people "loyal" enough to tell you what is being said in the languages you cannot understand and the spaces created for/by the international teams have a large number of "crossover" points with eachother and the main community such a move -could- be beneficial to all concerned.
the main risks are
"backstabbing" if you dont understand the language the group could easily be being discurteous of someone outside it.
"fear of backstabbing", one group being"paranoid" of another purely because whats being written isnt understandable but mentions a name.
"Divorce" if the international groups cease communicating outwards as often as they did while under the "english only" rule, the groups themselves can drift further and further apart to the point of becoming "introverted" and ineffectual.
We, as a company, not as a community site, operate an English only policy. We have customers from all over the world, Middle East, Continental Europe, Africa, etc, but just don't have the capacity to: employ multi-lingual translators, or to pay for translation services.
We do find that in the industries we sell to, English is spoken by almost everyone, but perhaps we are missing out on some customers who can't, or don't want, to speak English.
We also have some fun on the forums when using our British English and some of our customers and partners use American English
One of the issues missed here so far is that of cultural blocks to participation based upon language skills. In our work with SAP many years ago, we did a lot of research into this issue. While most senior level managers are very comfortable using English in business, many lower level employees who are considered bi-lingual are not comfortable using English in a community. They will if required, but their participation levels will be lower than expected. The main reason is that they do not want to make a public mistake in front of superiors.
We've found that starting in English is fine, but to capture the rest of the audience local languages will be necessary at some point. Most employees in English required companies (SAP, Cisco, Intel, IBM) will use the site just fine without any problems.
As for requiring translations to make sure you know what's going on, that's a trust issue. Either you trust your employees to use the tool properly or you don't. If you must know every word that is put into the community, then keep it in English. But that kind of defeats the purpose of internal collaboration, no?
Being in Canada, we have a sizeable amount of French speakers. The content posted online will always primarily be English but a good start would be for us to be able to offer our users the ability to change their interface language -- something that I understand Clearspace is supposed to be able to support but apparently it's not quite there yet.
We are looking to expand our community internationally through a partner organization so this discussion is very relevant to me. As we are in aviation, which uses English as a semi-official language, it would be very easy for us to simply say that everything will be in English. That probably will be what we *mostly* do. Latin America can be a bit of a different beast, though, and we may set-up a Nike-approach Spanish community or set of communities in which the content would be Spanish primarily.
I thought I would circle back and post update on are current thinking about how we will handle multiple languages inside our internal community.
First, a huge THANK YOU to the members of this community who contributed to our learning by sharing their insight and suggestions.
Quick Recap: As an international company, we have over 20 different native languages spoken/written by our associates. During the initial pilot stage of our community, we restricted language usage to English only. Now that we have moved to rollout, we wanted to bring the internal Community into alignment with the other electronic communication toolsets in use within the company and ensure the Community was available to our regional non-English speaking employees.
Below is the:
- the Code of Conduct restriction on Language Usage we had in place during the pilot,
- the new Code of Conduct on Multi-Language Usage,
- and, our Management Plan for Non-English communities.
As before, please comment and let us know what you think and your suggestions for improvement.
Pilot Restriction on Language Usage: Use English please. This Community supports an international team of corporate employees that communicate primarily in English. Also, we ask that native English speakers write plainly without too many cultural frames of references that are unique to a single region, area, or business unit -- and, be patient with non-native writers.
New Policy on Multi-Language Usage: The Community supports an international team of corporate employees who primarily use English in their electronic communications. Therefore, English is the designated international business language of the Community. However, as a global company, we realize there is regional linguistic diversity within our company. In recognition of this diversity, non-English languages are allowed in approved regional spaces within the Community. Please use the following etiquette when participating in the Community:
- when you are working within a space, respect the language in use and write your post in the designated language of the space;
- be patient with writers who are not using their native language to post, and when possible, bi-lingual employees are encouraged to offer assistance to others in translating or drafting a non-native language post.
Management Plan for Non-English communities
- The administrator of a non-English space must ensure that there are at least two Moderators who are fluent (reading, writing, speaking) in the native language. Moderators are responsible for monitoring all posts within the workspace (blogs, discussions, documents) to ensure the Code of Conduct and Electronic Communication Policies are maintained at all times. Abuse must be reported per existing corporate policy for Electronic Communications or Code of Conduct violations.
- Moderators are responsible to provide and maintain a custom list of profane words in the native language for the Clearspace Profanity filter.
- No formal, sponsored human or mechanical translation service is offered at this time. Bi-lingual employees may certainly offer assistance to others in drafting a non-native language post but this is considered voluntary.
- There is no corporate requirement or prohibition on multi-lingual posts. In some communities, this may be encouraged by the Moderator to support broader readership.
I've been thinking about language issues also and here is what I've come up with as a strategy (not implemented):
1) The menu language is fairly easy to translate using property files. This can help international users at navigate through your site. Unfortunately the UI language preference isn't part of the user preferences in CS. I would put in a feature request to make that a user option. I've tried to do this automatically (in another project) based on the user's browser setting but it's not always the right thing to do (especially if a user is visiting another site and or using a cyber cafe machine).
2) Create a language or region Group. Call it the (French|Spanish|German) Embassy. This will allow you to have a landing page and some location specific discussions and content. Don't worry so much about letting people speak their own language, it's still publicly viewable and it's fairly easy to get a translation if you are suspicious.
3) Translations Strategy options
a) Create a way to Link translations of documents but have it be a completely different document so that titles, tags and meta-data can all be translated. Look at wikipedia as a model. There are cross-links to the translation of a page in the other languages. This could easily be done via link property for each language.
b) Create a special document body for each language. This way someone could add a translation in their language and it would be coupled tightly to the original content. The problem here would be permissions because you'd have to open the document edit permissions to everyone.
c) Create a custom translation comment. This would allow the owner of the document to accept, reject or flag the comment with the translation. You could modify the templates for the documents to show a list of translations comments available. This would also be an enhancement request to Jive.
For a public facing site I would recommend 3c because it gives the document owner some control over the translations to their document.
One concept for 1C would be to provide a translate button on each document. When the user clicks on translate the document body would be send to a translation service. In many cases that would be enough for the user to get the gist of the document. If the user found the translation lacking they could be given a button to "Fix this translation" and CS would copy the text and allow the user to modify it and save it as a special translation comment.