Add gender and case inflection forms when relevant in translation strings

[maladrill]

In activity stream there are names of objects created by users. In inflected languages we need to translate them differently than usual (it is grammar case Genitive). Can you point files where I can find strings used in activity stream for displaying: Case, Opportunity, Contact and Lead.

Example: Administrator created a new contact Administrator converted a lead Administrator created a new case Administrator created a new opportunity

I will tag the strings in crowdin.com for other translators to enable them to translate it properly.

[pgorod]

@maladrill you are aware of the Crowdin site where we translate SuiteCRM, right?

https://crowdin.com/project/suitecrmtranslations

Is your problem about finding the strings of the Activity Stream on Crowdin?

Or is it the fact that the strings available for translation are insufficient for the case differentiation you need to do for your language?

[horus68]

@pgorod its the second option

the strings available for translation are insufficient for the case differentiation you need to do for your language?

The sentences used in the activity stream that uses the created a new is a combined sentence of 2 strings.

• created a new needs to be gender sensitive so we can have (examples for portuguese) criou um novo and criou uma nova to match the gender used for Case, Opportunity, Contact and Lead

Activity stream its not the only place that needs to be gender sensitive but its the most visible

[horus68]

The strings involved are from modules/SugarFeed/language/en_us.lang.php

    'CREATED_CONTACT' => 'created a <b>NEW</b> {0}',
    'CREATED_OPPORTUNITY' => 'created a <b>NEW</b> {0}',
    'CREATED_CASE' => 'created a <b>NEW</b> {0}',
    'CREATED_LEAD' => 'created a <b>NEW</b> {0}',
    'FOR' => 'for',
    'CLOSED_CASE' => '<b>CLOSED</b> a {0} ',
    'CONVERTED_LEAD' => '<b>CONVERTED</b> a {0}',
    'WON_OPPORTUNITY' => 'has <b>WON</b> an {0}',

https://github.com/salesagility/SuiteCRM/blob/hotfix/modules/SugarFeed/language/en_us.lang.php#L99-L106

[pgorod]

@horus68 I fear it might be even more complicated than that, because he mentions inflections (case genitive, dative, accusative, etc, like in Latin and Greek, I suppose), not gender.

So, if I understand correctly, he would need all module names in a different inflection, and the code is definitely NOT ready for that.

[maladrill]

It is generaly problem which is very visible only in Feed. The strings involved from modules/SugarFeed/language/en_us.lang.php can be easily translated and they are in fact gender sensitive. But the file does not contain contact, case, lead and opportunity strings which need to be translated according to grammatical case - Genitive. There are multiple occurences of these strings in total and all are translated using case Nominative which is mostly ok. I cannot find the right ones, it is like 4 needles in a haystack :-)

It is not essential, but can be very helpful for other translators (I have the comfort of making the translation better as my language is 100% complete), and I leave comments every time I find strings that shouldnt be translated as in every other case. And it also makes good impression on users, because Feed is right on the Home screen when you log in :-)

[pgorod]

I suggest changing the title to "Add gender and case inflection forms when relevant in translation strings".

This is not going to be an easy fix (I mean - it's not difficult, but it is a lot of work) but maybe there can be hope of fixing just the more visible issue with the Activity Dashlet, and in the long run perhaps this can all be improved.

And it would be nice to start a list of everywhere where this is necessary. Sometimes the best solution could be to turn the sentence around, phrase it differently, so that the inflection is not needed at all (maybe "New lead X created by Y", or "Y created a record of type X").

[maladrill]

Sometimes the best solution could be to turn the sentence around,

That is what I do every time I find it possible and in most cases it works fine. But in that paticular case all we need is to find the right strings and mark them for other translators to know how to translate them properly.

[maladrill]

I language file https://github.com/salesagility/SuiteCRM/blob/hotfix/modules/SugarFeed/language/en_us.lang.php#L99-L106

'CREATED_CASE' => 'created a <b>NEW</b> {0}'

What {0} means? Where is it filled from?

[pgorod]

It is replaced here, using the contents of $GLOBALS['app_list_strings']['moduleListSingular'], which probably comes from here (I didn't check).

Watch out because those strings are used in many other places, so in order to accommodate inflections they would have to be duplicated (or triplicated, or...).

Incidentally, it's funny how those initial labels you mentioned above are all lacking the standard LBL prefix (CREATED CASE instead of LBL_CREATED_CASE).

[maladrill]

Thank you @pgorod It seems it cannot be done, because it is used in many places where it has to be Nominative.

[horus68]

@maladrill please do not close this, so SalesAgility can take a look. Also please change the issue title as suggested to Add gender and case inflection forms when relevant in translation strings

@samus-aran this can be considered at least a suggestion for Trello

[maladrill]

A workaround would be not to call a global function, but to put strings for case, contact, lead and opportunity into language file in SugarFeed

[pgorod]

Yeah, don't just close this, it will eventually come up again in the future, so we might as well have a place where we aggregate our thoughts on the matter.

The solution for the Dashlet is not that complicated:

1. Create another set of labels for the modules, something like LBL_CONTACTS_SINGULAR_GENITIVE , LBL_ACCOUNTS_SINGULAR_GENITIVE etc
2. Get the code in the dashlet to use those labels instead.

However, some organization around this whole issue is needed. It would be nice if the languages that do not need inflection wouldn't have to translate additional labels.

The same goes for the Gender difference.

The general idea would be to REALLY try and minimize the multiplication, and then just multiply variations if they are both unavoidable and highly visible to end users (like these on the Home screen).

[maladrill]

There is one more issue related to SugarFeed. Some of the strings in modules/SugarFeed/language/*lang.php are written in capitals, for example:

  'CLOSED_CASE' => '<b>ZAMKNĄŁ(EŁA)</b> {0} ',
  'CONVERTED_LEAD' => '<b>PRZEKONWERTOWAŁ(A)</b> {0}',
  'WON_OPPORTUNITY' => '<b>SFINALIZOWAŁ(A)</b> {0}',

But when it is passed to the browser it is in lower case. It works fine as long as there are no special characters, because then instead of "przekonwertował" it is diplayed as "przekonwerowaŁ", as in the image below. There is an easy fix to that, and I tested in my system:

  'CLOSED_CASE' => '<b>zamknął(eła)</b> {0} ',
  'CONVERTED_LEAD' => '<b>przekonwertował(a)</b> {0}',
  'WON_OPPORTUNITY' => '<b>sfinalizował(a)</b> {0}',

[pgorod]

For the lower case, the solution is to change the code in these two lines of file modules/SugarFeed/Dashlets/SugarFeedDashlet/SugarFeedDashlet.php:

$modString = string_format($modString, array($modStringSingular) );
$this->lvs->data['data'][$row]['NAME'] = preg_replace('/' . $modStringMatches[0] . '/', strtolower($modString), $this->lvs->data['data'][$row]['NAME']);

into this:

$modString = string_format($modString, array_map('strtolower', array($modStringSingular)));
$this->lvs->data['data'][$row]['NAME'] = preg_replace('/' . $modStringMatches[0] . '/', $modString, $this->lvs->data['data'][$row]['NAME']);

My guess is that somebody simply wanted to lower the case of the module (changing Contact into contact, etc), but for simplicity lowered everything. And for polish weird characters, simply PHP doesn't know how to lower the case, so it leaves them alone... :-)

So my change is just to move the lowering of case to an earlier stage, when handling only the module name. This way the case of whatever we put in the app_strings (and translated strings) is respected. I believe those capitals in WON and NEW are deliberate, for emotional effect!

[rholighaus]

I fully agree with pgorod - in German, nouns are always capitalised, so to strlower() the translation results in grammatically incorrect spelling (and it confuses readers).

[horus68]

@maladrill @pgorod maybe separate this Issue in two and create a PR for the lower case fix presented here? @Dillon-Brown any ideas on the Add gender and case inflection forms?

[maladrill]

@horus68 - lower case fix is definitely to be separated.

[rholighaus]

I wonder if the entire phrase could be translated not using the {0}, so instead

'CREATED CONTACT' => 'created a <b>NEW</b> {0}'

it would be

'CREATED CONTACT' => 'created a <b>NEW</b> contact'

Translaters could take care of the grammar, upper/lowercase etc. as the label already refers to the module type (in this case, Contacts).

This is how I fixed the issue on our systems and it works.