Language-specific relationship names

[fisharebest]

Now that we have modules for langauges, we have somewhere to store logic for language-specific relationship names. e.g.

• cousins
• great xN grandparents
• Spanish consuegro / consuegra (child's spouse's parent)
• etc.

Each language can define its own rules/translations.
Anything that is undefined will get a translation of the English relationship name.

[DaPoHou]

That's great!Thank you very much.
I hope to give more examples and explanations.

[ric2016]

Should this be marked as solved? Other issues for specific languages reference this issue. These languages are not solved yet.

[ric2016]

Also, I really would prefer a more generic access point, e.g. in ModuleLanguageInterface

public function getRelationshipName(RelationshipPath $path): string;

so that specific languages/ custom modules get their chance to implement their logic differently, rather than having to provide an array of relationships. In your solution, how can specific languages define specific algorithms for splitting complex relationship paths?

[fisharebest]

In your solution, how can specific languages define specific algorithms for splitting complex relationship paths?

I guess you could extend RelationshipService and replace nameFromPath().

if ($language has special logic) {
  return special_logic(...);
} else {
  return parent::nameFromPath(...);
}

But when I get feedback from more languages, then I expect the logic will change.

[ric2016]

Is there any chance that you'll consider generalizing the interface, as suggested?

I think this has advantages as it decouples the logic from the interface. After all, what is the abstract goal here? In my opinion, it is to get a translated relationship path name from a specific language.

So using a method that just returns this string seems more flexible, and more in line with similar methods from LocaleInterface, such as 'percent($number)' and 'number($number)'.

The current implementation can of course still be used to support modules in implementing this, i.e. they could use the RelationshipService to provide the result, but it would be easier to extend this with special logic, without having to change the interface later.