CiviCRM Community Forums (archive)

Hi,

Im on the CiviCRM edTrends project. My english is not best please forgive my phrasing...

In our translations, we appear to have holes in certain areas of text which my first guess has to do with modified TS strings in the PHP that are not synced up with the POT maybe. I havent looked so just a guess.

But I was wondering if its something we already know about. Some strings that seem not to get recognized. In the attached example CiviContribute, CiviMember, CiviEvent and a strange one with CiviMail are not being picked up despite being translated and the PO is correctly formated and it seems to match the POT as well.

The CiviMail Admin screen translation is a strange one as it looses elements. I havent investigated this to any great extent yet but was wondering if there is preexisting knowledge regarding those items before I walk down the debugging road.

FYI-Also all PO files core, modules and so on are fully translated.

Thanks!

Thats correct. Well in reality the names are not exactly changing. To internationalize you would have to allow a user to naturally navigate the environment in order to promote ease of use and regional adoption.

Lets look at it this way.

Civi+Mail, as you know there are no latin letters native to the Japanese language and only a person who studied English would be even able to pronounce it, but perhapes not actaully understand the vocabulary, thus both parts mean nothing to the majority of Japanese-users (as an example) and they cannot differentiate CiviMail from CiviContribute or any other Civi+Module for that matter.

To properly academically illustrate this, heres an exercise. A correct professional translation of the CiviCRM modules would be:
市民メール
市民貢献
市民イベント
市民会員

Can you deduce which module is which as a non-Japanese/Chinese/Korean reader? This is basically the same position a Japanese person is in when they see the native English names of the modules which are not just random names but an informative label for a collection of fuctions. Clever word plays in english for sure, completely lost and meaningless in Japanese and most other languages with no latin/romance language lineage (eg. All of Asia, Middle East).

In our internal translations for our own clients we would use something similar to the above in a professional environment.

In a CiviCRM community translation we use the following (below) to ensure the Civi name is carried through into the translation for the sake of sustaining a cohesive identity. It is as correct as one can be while injecting a wholly incorrect set of vocabulary and characters into the language (latin letters again hold no meaning). It is a common approach by non-native speakers but less than perfect and you will find people will undoubtedly delete the Civi portion as it is a very unnatural to mix for the average non-English speaking user. Imagine in the same way if the default name for CiviCRM was hypothetically inverted and was 市民CRM as 市民 is meaningless to you. But to me, it means Civic+CRM, you would indeed drop 市民CRM in favor of CiviCRM if you want it to convey any meaning to a user. But a special exception can be made and a literary license can be used to come up with the following. But this license is limited to the title of the program and would not extend into the inner navigation of the program as it gets old real fast and suggest a program that is not properly translated or localized from the users perspective because the screen should be entirely familiar and navigation should be instinctively natural.

The Translation For the CiviCRM community POs;
CiviMail = Civiメール
CiviContribute = Civi貢献
CiviEvent = Civiイベント
CiviMember = Civi会員

Now, on our side there was a very lively conversation on this very subject on our own bulletin board among the English speaking Japanese in the Japanese Academic community that where very vocal with regards to what localization really means to them.http://www.edtrends.com/index.php/forum/1081-open-source-initiative/214-civicrm-and-japanese.html Its the difference between widespread adoption vs just curious tinkering.

fnakamura and edTrends folks:

Thanx for jumping in and helping out. This is quite important and valuable to us. I took the liberty of going through most of the forum posts on the edtrends site, a couple of thoughts:

1. Having JP/CN/non-latin based languages will help make civi a more complete product and also expose holes and deficiency in the current product

2. I do agree that Civi can not meet all the requirements for all languages. The question is, can we modify civicrm so folks can extend / modify the behavior in a easier manner and avoid the need for lots of hacks at every version. Drupal does have some excellent ideas on how to build an extensible system that we can learn from (and parts of it are already in CiviCRM)

3. Functional features like ACL's are scheduled to be rolled into civicrm in future releases (we are aiming to get that into core in 2.0) I suspect edTrends can help a lot in this regard

4. Things like Japanese calendaring are needed by other culture/community (like the hebrew calendar mentioned in a related forum). This comes back to point 2 and should give us insight into how to design a system that allows a fair amount of integration with "external" functionality. I think a similar argument can be made for japanese names/addresses

5. Would be good to get more details on the differences in the civic sector between JP/CN and european countries. Might help us do a better job of keeping core a bit lean and more focussed (maybe?)

This definitely opens up a new world for us, and we are quite excited to have u'll participate

lobo

Piotr,

Thanks for responding to my post. I'm sorry if I suggested we should abandon the Civi's, I meant to convey that we should keep the Civi on the top end, like CiviCRM but eventually drop them for module names.

Beyond the internationalization and localization reasons, I think we should promote a module/add-on type of philosophy to extend the core as intrusively as possible since, sometimes, people don't need such localized things to be in core like Hebrew/J-calendering but maybe its best to just have them load in as optional modules that can or can not be included in the default install. This way we don't need to weigh down the core with such things and make it be the traffic (the core) manager to all data moving in and out of the CiviDB in the future.

This will allow for non-intrusive functionality.

But from our perspective, preserving the Civi brand is important, not so much on the module level though as these things right now are basically core switched on and off. But, are certainly useful in explaining what Civi can do.