Support multilanguage nopes based on the Accept-Language standard header

[agomezlucena]

Why we need this:

The joke need to be multilingual for rejecting Co-Workers crazy ideas in their native language.

How this will work:

the user will sent us this request

curl -X GET ${NASS_URL}/no -H Accept-Language=es-es

the user will obtain a random negation sentence in the defined language like.

{
    "reason":"Ni harto whisky hago ese desastre."
}

In case that the user don't define any header or its locale it's not supported the expected result will be in english.

If you need any rejection phrases in Spain Spanish you can count with me.

[Fordi]

#5 should enable this. Once it merges, please do make a PR for Spain Spanish by adding an "es-ES" section in reasons.json.

[Fordi]

Also, seeing the translation - that is not a "soft" no like the English ones 😆 .

[hotheadhacker]

@Fordi thanks for your awesome contribution will check and get this merged soon.

Peace ✌️

[Fordi]

There are several PRs open now for i18n, all of which are incompatible. Just like a good open source project 😆.

To enumerate:

• Using Accept-Language:
  • I'd opened Multilingual support #5, but it was dependent on Sort / Deduplicate reason list #4, which I'd abandoned, as I thought Add multilanguage support with per-language rejection phrases #17 had a more elegant implementation.
  • @antoinekm opened Add multilanguage support with per-language rejection phrases #17, does automatic self-discovery of supported languages, via scanning a relevant directory.
• Using ?lang=...
  • @Josue616 opened Spanish Responses #32 for Spanish
  • @SirenTheSiren opened German translations #33 for German
  • @MYCBA opened Add Language Support with starting Turkish  #34 for Turkish

I urge us all to work together to nail down a single spec / implementation with the strengths and content of all of these, and to get @hotheadhacker's buy-in. My thoughts:

• I favor Add multilanguage support with per-language rejection phrases #17's implementation, as it adheres to web standards for language selection.
• I wouldn't be opposed to allowing the consumer to override with ?lang=..., since that makes ad hoc testing / debugging more straightforward for a developer.
• Runtime language discovery is IMO the right balance between minimal maintenance (you don't have to add a ref to a language file when adding a language) without imposing significant performance penalties (as you would with request-time discovery).
• Runtime caching of the reasons could become an issue if we get enough of them, but I can't imagine having more than a few megs of reasons, even across all languages.