Skip to content
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

Support run-time language switching #2

Open
felixLam opened this issue Apr 14, 2017 · 3 comments
Open

Support run-time language switching #2

felixLam opened this issue Apr 14, 2017 · 3 comments

Comments

@felixLam
Copy link
Member

felixLam commented Apr 14, 2017

We might consider providing an additional elm writer that creates multilingual modules. This would allow elm-apps to switch at runtime.

Assuming that the following current "modules" exist per language containing one string constant each:

  • Translation.Main
    • helloWorld : String
  • Translation.ErrorMessages
    • notFound : String

The multilingual mode would create a language definition, e.g.:

module Translation

type Language = De | En

It would then generate the following modules:

  • Translation.Main
    • helloWorld : Language -> String
  • Translation.ErrorMessages
    • notFound : Language -> String
  • Translation.Main.De
    • helloWorld : String
  • Translation.Main.En
    • helloWorld : String
  • Translation.ErrorMessages.De
    • notFound : String
  • Translation.ErrorMessages.En
    • notFound : String

The elm app would then use Translation.Main or Translation.ErrorMessages.

Example implementation of helloWorld : Language -> String:

helloWorld : Language -> String
helloWorld language =
    case language of
        De -> Translation.Main.De.helloWorld
        En -> Translation.Main.En.helloWorld
@ChristophP
Copy link

ChristophP commented Apr 15, 2017

@felixLam So in general this sounds a reasonable approach. Just some of my thoughts:

  1. For me (other than supporting JSON) it was not as much about runtime switching of the language as it is about not wanting to have to load and keep aroud lots of builds. I would like to keep it simple in that regard.
  2. I am not sure what you mean by language modules and how the language files you are using are structured. We are using the i18next client to load JSON files. We never really have many modules. We have one language file per language per app. So I don't really understand how that works with the modules or why you need them. One would suffice for the use cases I am familiar with.
  3. Also I don't have any experience with CSV or PO lang files, but it sounds to me like they are flat vs. the hierarchical format of JSON. So if I am correct you have to think about how t deal with nested values. The approach that I used here is to camelize nested values and make longer function names like I did here with the tigersRoar (https://github.com/ChristophP/elm-i18n-module-generator).

@tayloredwebsites
Copy link

Please look into using translation tables. I have dropped the idea of putting an Elm front end to a Rails site, because I will have to code, test and maintain four different sets of front end code: English, Bosnian, Croatian, and Serbian. Please look at the simple and effective approach that Rails uses for internationalization. see: http://guides.rubyonrails.org/i18n.html

@purohit
Copy link

purohit commented Jan 3, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants