Respect the URL parameter specifying a language

[mohammad-suliman]

currently, the app doesn't adjust the language according to the URL parameter specifying it. For example: if we go to the following URL, the app will be displayed in english although the URL is specifying Hebrew: https://sensoryinterface.com/?lang=he#

[S0AndS0]

This code posted on Issue Create tutorial page and background material text in Hebrew #43 could be utilized with this to provide automatic translations, however, if this project is going to continue with manual translation then it may be easier to have each language within a sub-directory, eg...

https://sensoryinterface.com/en
https://sensoryinterface.com/es
https://sensoryinterface.com/he
https://sensoryinterface.com/ja
# ...

... and have some redirection script on the root index file at https://sensoryinterface.com/index.html, if what I've read about HTML status codes be true then 307 likely is the code that should be sent to browsers for a temporary URL redirection.

[oferb]

Why subdirectory and not param?

[S0AndS0]

With manual translation I don't know of any other ways to organize pages other than either a sub-directory per-language or prefixing file extensions, eg...

https://sensoryinterface.com/index.en.html
https://sensoryinterface.com/index.es.html
https://sensoryinterface.com/index.he.html
https://sensoryinterface.com/index.ja.html
# ...

... note though that prefixing file extensions could confuse some web-servers configurations.

That stated, both param and sub-directories could be used. By using the param to respond with 307 status code to the sub-directory, however, this would likely only be required if manual translations are maintained. If instead auto-translation where utilized the param could be used to re-fill language choice.

Recently I published GitHub -- liquid-utilities/includes-translate, a plug-in for Jekyll built sites, the underlying code of which could be adapted for this project; ie no need for Jekyll or Liquid comelier. Feel free to test out the live demo and let me know if core features would be acceptable within this project.

[oferb]

We have 2 kinds of translations - ones using i18s.js where the page is the same and we replace strings. The other are tutorial pages which are Markdown-based and there we actually write the Markdown separate for each page.

The subdirectory-per-project suggestion is for the tutorial pages, right?

We do want to keep manual translations (for Hebrew and Arabic) because they tend to be better quality than automatic ones, and we're native speakers.

[S0AndS0]

The translations that use i18s.js, once renamed, could likely be moved too and changed to .json files their respective directories, eg something like...

.../en/dynamic_translation.json

"about": {
  "language": "Language",
  "direction": "ltr",
  "title": "The Sensory Interface",
  "tutorial": "Tutorial",
  "theTeam": "The team",
  "howWork": "How it works",
  "aboutUs1": "About us",
  "description": "The Sensory Interface project aims to help people with low vision and blindness understand tabular numerical data such as spreadsheets.",
  "getStarted": "Get started",
  "learnMore": "Learn more",
  "aboutUs2": "About us",
  "aboutP1": "In today’s world, where data is ubiquitous, we view data accessibility as a basic human right. The Sensory Interface project aims to provide an interface to numerical data for any purpose, be it Scientific Research, Software Development, Education etc.",
  "aboutP2": "This data is typically visualized using graphs, charts, heatmaps etc. You could think of these visualizations as the visual interface to the data. We aim to provide a multi-sensory interface to the data. This interface uses sound and touch, in addition to the visual channel, as a means to convey the same underlying data.",
  "aboutP3": "Our hope is that by doing this, we will make work in fields such as Scientific Research, Data Science and Machine Learning accessible to people with low vision and blindness.",
  "getStart": "Get started",
  "letsGo": "Let's get started",
  "stage1": "1. Go to our tutorial",
  "stage2": "2. Define your graph",
  "stage3": "3. Start using it!",
  "goTOtu": "Go to tutorial",
  "theTeam2": "The team",
  "mohammad": "Mohammad Suliman",
  "mohammad2": "Software developer, B.Sc in Computer Science from Technion, blind and wants to help other blind people in STEM education",
  "ofer": "Ofer Bartal",
  "ofer2": "Software engineer, X-Googler, Co-founder at <a href='https://wakka.ai'>wakka.ai</a> with a goal to help people learn and work in software",
  "credit": "This project is run by The Public Knowledge Workshop (a nonprofit). For more details and collaborations, please send an email 'to': info@sensoryinterface.com",
  "selectLanguage": "Change language"
}

.../some.js

const translations = {};

require('.../en/dynamic_translation.json', (data) => {
  translations['en'] = JSON.parse(data);
});

... the main benefit of which are...

• JSON error checking for key/value pares

• allowing any languages to be loaded and then selected via client choice and JavaScript

... but yes at the moment having separate directories would be for those that are either .html or .md files.

Indeed it makes sense to keep manual translations for languages that there are native speakers willing to maintain'em; my main concerns are organization related such that adding automation or more human translated content doesn't create confusion or conflicts.

[oferb]

We already have what you mention in . the main benefit of which are... with the current mechanism. The main difference is whether the "dynamic_translation" (which are actually static, no?) are in json vs in js. Or am I missing something?

[S0AndS0]

The following JSON examples all fail, where as JavaScript objects wouldn't care...

{
  "key": undefined
}

{
  "key": [
    "one",
    "two",
    "three",
  ]
}

... using JSON for this structured data is kinda what JSON is intended for.

Furthermore, const data = JSON.parse('{"key": "value"}') is faster than data = {key: "value"}. And sourcing JavaScript files within HTML means two file at minimum (though more likely three) to be opened whenever languages are added or edited, where as using require within the script that requires'em means two files at most are opened for edits.

It may seem a bit of a nit to pick, but from my perspective it's more organized, easier to maintain for authors, and faster for client-side parsing.

[oferb]

Why do you need to edit more files?

To summarize my thoughts:

• Having /en, /he, /ar folders for static translations is a good idea.
• I wouldn't want to add dynamic translations at this point, as they complicate things (as any addition does) and that's not currently our bottleneck. English, Hebrew and Arabic have enough blind people. We currently have about 10 users testing the system. There's many millions fluent enough to use the system in the above 3 languages. So it's mostly prioritization. It's not that I don't think we should translate to more languages, just, not now.

Currently our bottleneck btw is more about:

1. Getting the thing to work properly for all combinations of: Screen reader, Braille display, OS (and version) browser (and version). It's a combinatorial number of possibilities and we're now discovering issues all the time via user feedback.
2. Getting the tutorials and overall experience simple enough for people to follow.

[S0AndS0]

Having static files does sound like a more agreeable option as there'd be less scripts/lag on the client-side, but that'd also bring up the previous Issue (#27) regarding some form of site building from templates. While I'm fond of Jekyll because it's easy to use with GitHub Pages there's also MustacheJS which, much like TypeScript, could be pre-built prior to pushing.

Granted there's a trade-off when adding a site-builder, but this project is already at the point that individual pages have styling differences and links between pages are also breaking.

My concern in this regard is maintenance and accessibility, while I totally agree that humans are better at translation than anything Google (or any other automated service) provides, as the pages for this project expand having some form of automation will afford more time to features and fixes oriented commits.

Additionally having automated translations would provide anyone that wishes to contribute more accurate version(s) a starting point; ie. it'd be more of correcting the robots instead of re-writing each page.