Dear fellow GraphHoppers,
not sure if this is a known issue, haven’t found anything with the search function.
If I request: /i18n/de I get a default and an en object as json.
If I request /i18n/en I get only en.
I think we should try to make this consistent:
Either return de and en for /i18n/de or return default and en for /i18n/en (which would be redundant, but a non-breaking change). I understand why we do it like that, but it feels a bit inconsistent. If I wouldn’t be aware that en is the default, I would assume that when requesting /i18n/en I get a default object as well.
WDYT?
Cheers,
Robin
What exactly is the problem with this? I think the naming should probably better be ‘fallback’ instead of default and then it should make more sense?
But the default is not the fallback. The default is the selected language, except when I request en, then I only get en and no default. So I think en should be called fallback and the requested language could be named: trans or by it’s language code. Don’t you think?
I’m still unsure if I understand the problem 
… so if I request English I get en with no fallback, when I request German I get German with the English fallback in case some properties are not translated into German. Over what exact problem did you stumble or just the inconsistency?
It’s just about the inconsistency Everything works, but not as expected ;). I found this when writing tests for the API, I started with Englisch. Then I wanted to write a test for German, but the object was not de but default.
1 Like
Ok, and the change would be backward compatible? Then please feel free to submit it as PR
Yes, but we would send duplicated information for the en case, because for en I would also send the default object which is just the same as the en object. This would remove the edge case. Do you still want a PR for this?
Why can’t we do this on the client side? I mean introducing duplicate information is not only an improvement 
I thought you would say that . Everything works and writing client code to use the current translations is not that hard. It’s just that I am a bit unhappy with the naming and having a special case for i18n/en. Maybe we should just keep it in mind, when we might release a new API version to have a look at the translations again?
… so if I request English I get en with no fallback, when I request German I get German with the English fallback in case some properties are not translated into German. Over what exact problem did you stumble or just the inconsistency?