Localization: implement i18n_string()

I'm not familair with translated outside of using t() everywhere; what code change is required for this?

Eeek. I'm overly familiar with these sort of translation problems and it's going to be super delicate to solve this. :-)

We probably shouldn't be putting "Space" as in a oa_space into t(). Content type names are usually translated specially via the i18n module, and so we should probably be loading the name in a way that will trigger i18n. This way the normal word "space" can get translated by t(), and the content type name "Space" will get translated by i18n_string().

I hope that makes sense... I'll do some experimenting later if I can find the time.

Well, since content type labels aren't translated by t(), but rather by i18n_string(), I think it'd be best to avoid t() altogether, IMHO.

The challenge is really is getting the label without calling i18n_string() directly, because we don't want to add a dependency on i18n! I know that it hooks in somewhere and overrides the type labels for the current language. If we can just find that, then we can make a single call that will work both with or without i18n installed.

The best solution to this is probably to make the term "Space" a user-configuration string. The Toolbar already has string variables for this, but using something more global to OA2 would help. We won't be able to change it everywhere in OA2 where Drupal or other modules are in control, but that should get rid of any calls to t().

@mpotter: So long as that configurable variable declared itself to the variable module via hook_variable_info() then it would be translatable via the i18n module and multi-lingual should work! The only issue will then be with plurals, but that's a constant issue with many things, and I'm not sure what the right solution is.

@mpotter:
I've thought about finding the best suited translation for the word 'space' in this case. In the end I get the german word 'Bereich'. When I translate this word back to english I get the word area.

I also think that 'area' better hits the purpose and description of the 'spaces'. Fur subspaces you can use 'subarea'

.. and the double meaning of 'space' is history.

Sorry, but we are not going to change the terminology at this point. Area and subarea were suggested in early terminology discussions but rejected because test users found them more confusing than Space. Spaces is a term used in many other collaboration, intranet and web portal products as well.

Still just planning to make this a configurable variable in the future, but there are many other localization issues to be fixed, so postponing until we have a project to localize OA2 (or somebody else does).

Thank you for the quick response.
Is it possible to fix the precise translation only in the Open Atrium * .po - files?

How can I export the .po files only for selected modules so that it is possible to generate this only for OA-Modules after I've find a perfect translation?

Yes, it should be possible to fix in the direct *.po files. For example, the t() function is called for phrases and not individual words. So you can add a translation of "Become a member of this space" that is different from the translation used for "The username cannot begin with a space."

Sorry that i posted a bug report and possible solution in the oa_core issues list...
As it actually occurs in many submodules. Please see here:
https://www.drupal.org/node/2313737

This could be a possible solution for the case. This means that the actual code such as oa_space does not have to be changed, but the t(space) etc could be change to t(workspace) or t(projectspace) or similar

The term space in itself is not clear enough, other projects would also interfere, when Space means Outer-Space etc.

If you replace the translation of word «group» by the translation of word «space», you will make a good translation by chance if the target language translates both sentences (with group and with space) the same way.

In french for example it is not the case :

"You are the group manager" -> "Vous êtes le gestionnaire du groupe"
"You are the space manager" -> "Vous êtes le gestionnaire de l'espace"

The result is :
"Vous êtes le gestionnaire du espace", which is wrong.

You have to give the user the possibility to translate the whole both sentences like this :

<?php
// profiles/openatrium/modules/contrib/oa_core/oa_core.module
/**
 * Replace "group" term in OG with "space"
 */
function oa_core_replace_group(&$field, $context) {
  if (isset($field)) {
    if (isset($context['entity']->type) && ($context['entity']->type == OA_SPACE_TYPE)) {
      $sentences = array(
        'You are the group manager',
        'Unsubscribe from group',
        'You are already registered to another group',
        'You are already registered to @count groups',
        'Subscribe to group',
        'Request group membership',
        'This is a closed group. Only a group administrator can add you.',
        'Private group',
        // perhaps some others strings …
        // …
        );

      $space_sentences = str_replace(
        array('group', 'Group'),
        array('space', 'Space'), $sentences);

      $cb = function ($s) {
        return t($s);
      };

      $field = t(str_replace(
                 array_map($cb, $sentences),
                 array_map($cb, $space_sentences),
                 $field));
    }
  }
}
?>

The terms "space", "spaces", "Space" and "Spaces" should be replaced by a more accurate term such as "workspace" or "projectspace".

Space is ambivalent and can mean many things in other languages or other contexts and should be either renamed to the above (I have used "Workspace" in my personal fix). Using the more accurate term work- or projectspace keeps it with mpotters desire to adhere to the term "space" which indeed is used in other Collaborationtools, but defines it more clearly. The English translation can then still be "space" for the userinterface, this has just to be defined in the english .po file. This way we work around the problem with the contextualized Translation set by using the language more accurately. Also, the term subspace does not have to be changed.

Example in the German Language Space is elsewhere translated to "Leerzeichen" which is completely different. The term Space here should be translated as "Arbeitsbereich" or "Projektbereich"

mpotter wrote:

[…] should be possible to fix in the direct *.po files. For example, the t() function is called for phrases and not individual words. So you can add a translation of "Become a member of this space" that is different from the translation used for "The username cannot begin with a space."

But that simply is not true, t('space') is called for individual words and both for the meaning: "empty space between words" and "workspace" and that is where it is most disturbing, as long as it were in a sentence the context mixup could not happen.

This Issue affects also additional projects within the OpenAtrium Distribution but can be fixed easily by replacing at least those occurences that are "single term" (e.g. t('space'), t('spaces'), t('Space'), t('Spaces')) with their equivalents.

Would it be good if I cloned the repository and and applied that change, would that have a chance to end in the master? Otherwise I would not make the effort

@triple5: See my comment in #2. This is basically the exact use-case for i18n_string(), rather than t(). i18n_string() allows you to give the translation a name (rather than using the actual text as the idenitifier), so we could replace all instances of t('Space') with i18n_string('openatrium:space', 'Space') and allow translators to give the correct equivalent for 'Space' in the sense that Open Atrium is using it.

Anyway, I don't have the time to implement this, but I think that is the correct solution!