CiviCRM Community Forums (archive)

As per the relevant blog post, we’re considering making some of the multilingual fields back monolingual again.

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_text 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.