search

inrupt / solid-react-sdk

Solid React SDK by Inrupt
MIT License
81 stars 5 forks source link

i18n #10

Open justinwb opened 5 years ago

justinwb commented 5 years ago

Solid is a decentralized worldwide movement, with the ability for applications and data to interface across borders and cultures. As such, it is important to have robust internationalization support from the start. As many developers know, i18n is something that is fairly painless to incorporate when you start making something, and quite a pain to do after the fact. We aim to provide code and demonstrate best practices for internationalization in a linked data Solid world.

justinwb commented 5 years ago

We're taking a two-phased approach to i18n. This warrants a bit of explanation, starting with two key points:

  1. i18n is something that you want to incorporate as early on in development as possible. It's barely any extra work if you do it from the start. OTOH, the lift is much larger when you have to go back retroactively and integrate it. We want to avoid that.
  2. We believe in turtles all the way down. Linked Data should be used throughout.

We believe that LDFlex is the most appropriate place to implement i18n, and so that's what is going to happen. That won't be ready immediately, so we're going to use standard tooling from i18next in the interim. This will get things split out into JSON, and will then be very easy to migrate to turtle or json-ld when LDFlex is updated.

To recap:

james-martin-jd commented 5 years ago

Phase 1 of the i18n plan was released today in v0.3.0 of the React generator. It uses react-i18next and standard resource JSON files (with English and Spanish shipping with the generated application).

konobi commented 5 years ago

Might also be good to keep in mind the linguists view of the problem, especially when it notes language specific edgecases: https://metacpan.org/pod/distribution/Locale-Maketext/lib/Locale/Maketext/TPJ13.pod

brownhoward commented 5 years ago

@konobi Many thanks for the link. A very interesting read that I have encouraged the developers working on i18n and L10n to read. Thankfully at this point we are only translating static labels, but as we continue and undoubtedly need to handle parameterised translations with an extended set of languages, this seems like a good approach.

jpaulin commented 4 years ago

Mindful (or less so) middle comment: i18n, but no "Finnish Excel VisualBasic" problems, right?

Backgrounds: I mean I've single- and firsthanded encountered a funny problem around 1998. Was programming VisualBasic for applications on MS Excel. I did a program to track some statistics in a cable manufacturing factory. The factory had Finnish locale Windows installed, while I had English locale at home on my PC. Guess what? Yes, Excel's VBA language had been somehow really half-baked translated (the actual programming language keywords), so my code didn't work. I would've probably had to use some esoteric transpiler to get my source code switched between FI/EN and back. The code worked only in one place, ie. where Windows had "correct" language settings. And I think that was a big turn-off for certain aspects of i18n 's usefulness.