Paging all multilingual CiviCRM users: We’re considering turning some of the multilingual fields back to be monolingual (i.e., have the same values in all languages, even on a multilingual installation), and your feedback on this is crucial. Since the introduction of multilingual capabilities in CiviCRM 2.1 we only ever added new fields to the multilingual set (fields that can have different values in different languages). Most of our choices were right, but after a couple of CiviCRM versions we’re hearing feedback that some of the multilingualisations cause more harm than good. Thus – we’re considering turning the following CiviCRM fields (in practice, their counterpart database columns) monolingual:
Contact names
civicrm_contact.sort_name, .display_name, .first_name, .middle_name, .last_name, .household_name, .organization_name and .addressee_display: having different first/middle/last names in different languages (or, what’s more important, scripts – like Cyrillic originals and Latin transliterations) was the initial example for multilingual support, but we’re hearing that it’s not really a popular feature. Do you know of an installation that uses different first/middle/last names for the same contacts in different languages?
Addresses
civicrm_address.street_address, .supplemental_address_*, .city and .name: we initially thought that it would make sense to be able to spell the same physical address with, say, English and French in Canada, and then use the given contact’s preferred language – but, again, we’re told that in the vast majority of cases the address is input in one version only, the preference of the contact. Do you know of an installation that depends on addresses being multilingual?
Mailings
civicrm_mailing.name, .from_name, .subject, .body_html and .body_text, as well as civicrm_contact.email_greeting_display and .postal_greeting_display: our initial idea was that mailings will be multilingual in nature, and then the contacts’ preferred languages will decide which language version of the mailing a given contact receives. It turns out many (most?) multilingual installs actually prefer to send separate, monolingual mailings to language-separated subsets of contacts instead (and the fact that multilingual mailings were sometimes empty didn’t really help either). Do you know of an installation that strongly prefers to send a multilingual mailing, rather than separate language versions in separate mailings?
Mailing components
civicrm_mailing_component.name, .subject, .body_html and .body_text: even with monolingual mailings it might make sense to have an universal, multilingual header/footer that you use for all of them (and which contents are auto-selected based on the preferred language of the recipient). On the flip side – having monolingual mailings, but multilingual mailing components is confusing (to say the least). On the other flip side – going back to monolingual mailing components means you have only one version of (re-, un-)subscribe and opt-out templates, and the burden of having them in the right language is on you (although it should be doable with a bit of template code, to the tune of {if $contact.preferred_language == 'en_CA'}…Canadian English…{else}…Canadian French…{/if} or thereabouts). Do you know of an installation that depends on having multilingual mailing components?
Please comment
Of course any comments on this issue are more than welcome; if any fields are to be turned monolingual we’d really love do to this to them before releasing beta1 later this week. If you’re wondering what other fields are multilingual – Xavier created a nice list of them on the wiki.
Comments
I don't work with any multilingual installations, but perhaps you could also post this in the forums for more exposure. I think more people may visit there than here.
Good idea, thanks for the reminder. I did post it yesterday, but with no response so far. I’ll revisit the forum thread before making calls on this.
My situation may be an edge case but I need to store a English version and a alternate(Hebrew) version of someone's name. However, I am using a custom field to store the alternate version because I needed to use the alternate version in a self-service profile field. I was not able to find a way to add a multi-lingual field to a profile, so I did not turn on multi-lingual features.
Also, the alternate version of the name did not fit into assumptions about "first name, middle name, last name". ( in this case the name is a personal first name, then the personal first names of both of their parents. In some situations only the personal first name is needed ( like for a student's name to be used in class), other cases the whole thing is needed (Like for preparing a formal document or certificate)
Doesn't seems to be an edge, and the custom field road you took seems to be the best one.
X+
I'm running a tri-lingual site using Drupal and CiviCRM. I've never used multilingual fields for names and addresses, but the possibility to send messages (print or e-mail in different languages is definitively an advantage and it would be nice to preserve this. Although,the possibility to send separate mailings is also an option.
Hi,
When we did at the code and although the database was multilingual, looked as the interface wasn't.
As you said, doing several mailings (one per language) works as well (and is easier to test)
first/last/middle names. So the english name is very very different than the chinese name :) We should definitely send an email to jimmy/charles and get them to comment
lobo
Good idea, I mailed Jimmy, Chang and Charles for their comments.
Thanks for lobo and shot gather us into this discussion.
In most case, monolingual is worked fine in our case. The main reason is that organization only have capacity to maintain one language of basic information of contact.
About names in Chinese, we doesn't have much problem since the feature added of "display name format" in global configuration in version 3.2. The only problem now on display name is that this can't configurable person by person. Most foreign doesn't have Chinese name, but most Chinese have English name. Sometimes, such as event registration, the attender will be foreign and use their English name to register the event. But when we only have one global configuration of display name format, we will have error on display "Jimmy Huang" as wrong "JimmyHuang". I think the situation of address is the same. Add the feature of config display format by contact is better than using multilingual(in our case).
For the CiviMail, even if I didn't use the feature of multilingual mail, I think the feature that we can send mail by the prefer language of contact is a good enough. I'm not sure if this is the same topic of CiviMail multilingual database.
I agree with all the above changes. In some cases as with mailings it's just more difficult for clients to deal with a multi lingual mail out rather than separate lists/mailings for each language.
I've also found no resistance to monolingual dates and times as Quebec uses yyyy-mm-dd and 24 hr clock and it is the international standard and less ambiguous than the US usage sometimes used in English Canada.
I don't think it is important to have multilingual names for individuals, but it is nice to have it for organizations. One of my clients enters these separately so that depending on the language of communication the appropriate one can be used (French language mailings for certain issues, English language mailings for others). They are an association in the cultural field and organizations take the languages they present themselves in seriously - members offering bilingual or only English or only French services can be important. Of course, the work around that is possible is to put both languages into the name field for bilingual entities. Having translations of the Org name also helps for listings, I believe, on their 'mirrored' bilingual sites (I used mirrored to mean every piece of content on every page is available in both English and French).
A few provincial sections of the New Democratic Party of Canada are using CiviCRM. In one bilingual province the language of the constituent as best that could be determined was used to set the language format of addresses when importing from a bilingual voters list address format. Custom code external to CiviCRM did the translations. These clients do not have a significant need to maintain more than language format for an address even though they sometimes use English and sometimes French.
However, one of the original purposes of having different formats was to improve the ability to parse addresses. While this is used currently only for CiviCampaign walk list reports so far as I know, the original rationale - to improve duplicate match rates - is looming larger at the moment. A provincial section of the NDP is looking to significantly beef up and automate duplicate identification and merging in CiviCRM to handle millions of contacts. They don't currently need to support French addresses, but they do deal with the bilingual federal voters list as an import source. Down the road I can see others potentially including the Green or federal NDP wantiing this. I also had a Conservative operative wanting to roll out a CiviCRM package to constituency associations within the last two weeks for the election that was just called today. So I tend to want to see that left in.
With regard to sending multilingual mailings, I don't have clients that are doing a great enough volume of mailings with CiviCRM in French and English for it to be a significant problem to do separate mailings by language. I think they are doing that for simplicity now. Others do bilingual mailings as they do not know or have confidence in the language preference of their constituents.
With regard to Header and Footer content, if they are going to be doing separate mailings for French and English then they would be comfortable with using only one language at a time. It would NOT work however if they had to go in and change system settings for link text back and forth. This would force people to do bilingual mailings, which isn't always great.
HTH.
Here is an overview of Koumbit's experience dealing with multi-lingual installations.
First, I should mention we use multi-lingual mainly in order to have bilingual profiles and contribution pages, and this works great. For other features, while it may be a "nice to have" in some cases, it was never considered a blocking issue.
* contact names: individuals are never translated, organisation name maybe. However, even for organisations, we will generally put both names in the field. For example, if it is an anglophone organisation based in Montreal, they will generally also have a name in French, but everyone knows them anyway by their English name. It is not natural for people to think in what language is the UI before doing a search.
* Addresses: on the projects I worked on, we did not standardise addresses. The postal service usually determines the location of a recipient by the street number and the post code. Their biggest requirement is that the postcode be written on a separate line. Also, we assume that people will not be surprised to see their address written in the form that they have entered it.
* Mailings: technically, this is an interesting feature, but in practice does not work well. First, on a technical issue, the only way right now to do a multi-lingual mailing is to first enter the data in one language, go back, switch language, and re-enter the second language. Then, all the practical issues: translations may be late, or more importantly, the person sending the English newsletters might be different than the person sending the French newsletters.
* Mailing components: it seems to me that going monolingual will avoid some strange bugs or inconsistent behavior (monolingual mailings with multi-lingual header/footers). I also imagine having a smarty function equivalent to the "language_sections" module of Drupal (http://drupal.org/project/language_sections)
On a more general (and perhaps technical note), I would mention that contact name/address can be particularly confusing since it often happens that the user does not notice in which language is the user-interface, so an address might be updated in one language and then the user will not notice that the english and french addresses are not the same anymore.
Mathieu (bgm on IRC)
Bit late here, but I thought I'd chime in.
Just getting started on CiviCRM and implementing it in a multi-national, albeit very small, organization. Three different nationalities, a myraid of language abilities. Some contacts are English names, some Khmer names, most Chinese. For our Chinese staff, having only the pinyin (romanized) name is confusing because two people may have the same pinyin name but different characters. We are using First Name for the whole pinyin name and Last Name for the whole name in characters, then Nickname for any English name our contacts might have.
Our constituents don't register themselves for events, as most don't have a computer or very good internet access at all, so we're able to control it as we wish.
Hello,
When CiviCRM will be translated in french language ?
Regard
Jacques.
---