-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Language-specific relationship names #36
Comments
The acual implementation will be freely customizable in each language. Additionally, support common cases: Re 1.: Provide a DSL so that (hopefully) non-developers can provide the language-specific logic in a descriptive manner rather than via regexes and switch cases. Example for German (second term is for genitive constructions):
Re 2.: |
About language specific files -- why do not create dummy (unused in code) php file with "static" strings, which can be translated by usual way (gettext)? |
Because different languages require different strings anyway. In German, we only need
while in Slovak we need to distinguish
So we need language-specific files anyway, which have to be created by developers who are familiar with the respective language. I don't see much benefit in adding another layer. (The current approach in webtrees is different, but unsustainable in general because it requires all languages to translate a large number of 'exotic' strings, many of which are only relevant for a few languages) |
I will try to make a Slovak file with the actual translations used in webtrees. Ladislav |
Ladislav, that would be very welcome for testing! Once we have that file, I'll create a proper release. Let me know if you need help with the more complex cases i.e. stuff like
|
OK, in provided example i see common pattern, thus we can ignore language specific names and and stay on English placeholders:
This will produce three English strings:
Thus in code is enough to split languages into two groups -- one with common name, and one with gender depended name and use dummy file for strings. By this, you (as code maintainer) can simply add English strings and leave translation to translators. This approach is already used in webtrees in more strings... |
But this is just a simple example. The differences between specific languages are far greater. See e.g. all the switches for different cousin numbering systems here. That's exactly what we want to move away from!
And it is not a good solution in this case, as described e.g. here by Greg:
I agree with him that we need language-specific code for this. |
Sometimes its time to ask about the very basic translations :-) spouse = Ehepartner = ??? Partner = Partner/Partnerin = partner/partnerka should be used for "families" without mariage. Or am I wrong? |
In the current path generation logic, 'spouse' occurs in the path only in case of unknown gender (i.e. in practice almost never in this context?). In the DSL, '->spouse()' can be used if the actual gender is irrelevant. The marriage status currently isn't addressed (see Greg's comment in the main issue), except for relationships of path-length one. I'm currently using the old implementation for these short paths anyway, so it should be ok even to skip those. Or do you need the marriage status for the more complex definitions (uncle, cousin etc.) as well? Ultimately we'll probably have to add
and so on for languages that want to cover all those cases as well. |
We have look into it in depth. Is needed in genealogy to differentiate between married and not married partners? IMO not, they already constitute pair -- nowadays more and more children comes out of married parents. We even need to not distinguish gender in husband/wife terms -- consider that both can have same gender nowadays and use recommended way (a read it somewhere on GEDCOM related site, no link) and consider both tags (HUSB/WIFE) as backward compatible, not as gender related. IMO, we need to apply the KISS pattern/principle. As we never will be able to construct proper translation of all combinations in the tree and in all languages, we will need to define some boundary of translatable relations and for all other combinations to use "Terrible to describe, see chart". |
I think this is a sensible approach. I hope these complex terms (step-x, adopted y, ex-z) are only relevant for simple one-step relationships anyway (nobody refers to a 'step-cousin once removed ascending' and so on). At the same time, I think it still make sense to have them for the simple relationships (just like in the original implementation), otherwise we'd have to use 'partner' everywhere even in case of married couples. So for now just assume that all one-step relationships are covered elsewhere and don't have to be defined in LanguageXxxExt.php. Edit: One-step relationships are now supported (extending the original possibilities e.g. 'adoptiveParent'). |
Initial version is now available in release 2.0.15.1.0. Supported languages: English, German, Slovak. |
Great! Well done! I have done several tests, all are perfect. Only one minor remark: in German I would prefer Ur-Ur-nnn instead of 2xUr-nnn. If there are four or more "Ur" then 4xUr-nnn is ok. |
Regarding the "2xUr-" cases, I agree. The resulting term "Ur-Ur-" is only minimally longer anyway. I'll adjust this. But I think I'll keep the "3xUr-" cases. |
Dutch added and German terms adjusted in 2.0.15.2.0. |
Work on this has finally continued in webtrees itself. Unfortunately there is no chance of getting the solution implemented here integrated into the webtrees core. I'll keep it for now, but it likely won't be developed further. |
As there is no progress in webtrees for this issue, I'll implement this here first. Hopefully we can move the functionality to webtrees eventually.
Main goals:
Out of scope:
The text was updated successfully, but these errors were encountered: