Support loading articles from other languages

[waldyrious]

~If not the interface itself, at least the content.~ edit: as discussed below, this issue will tackle only content multi-language support, and others will be opened to address the interface translation.

apiUrl and article.url need to be configurable.

[Jan-Ka]

Shouldn't be too hard to implement, just a simple data structure to hold all of that T9N data:

var availableLanguages = {};

availableLanguages["en-GB"] = {
  subdomain: "en"
  ui: {
    searchButton: "Search"
  }
};

availableLanguages["de-DE"] = {
  subdomain: "de"
  ui: {
    searchButton: "Suche"
  }
};

var userLang = navigator.language; // get's something like en-GB, en, de etc.
magicUITranslatingFunction(userLang);

But we should maybe establish some packaging beforehand including minifying so we can separate the translation stuff away from the search and UI? I think I can whip something up in an hour or two.

[waldyrious]

I would actually love to fetch the translations directly from https://translatewiki.net (where MediaWiki itself is translated), rather than duplicating the data in this repo. Since TranslateWiki's platform is based on MediaWiki, the it should be possible to make API calls to fetch the relevant translations.

This would require an Internet connection, but the entire Primerpedia doesn't work unless it's able to make requests anyway, so I don't feel it's a prohibitive choice -- especially since English would remain as a fallback should the requests fail.

What do you think?

[Jan-Ka]

I think I don't understand this completely because I do not know how translatewiki.net works.

As far as I understand we could make a Page there and use it to translate Primerpedia, and then extract said Translations via an API. I would probably look through https://github.com/wikimedia/mediawiki-extensions-Translate to extract it, because I couldn't find a proper documentation skimming through the project.

I don't really like the extra request but I see the appeal of it. We could do the same as mediaWiki and get a snapshot for releases (if/when we start doing that). That would have the benefit of letting the user decide what translations to offer (by simply removing the files). BUT - since we don't have direct access to files we would need some Installation Process anyway so we can ignore that right now :)

Anyway, till then I would say that we cache our translations on the client (localstorage) and track some arbritrary TTL. We talk about 3 or 4 strings maybe?

[waldyrious]

I think it might be better to separate the "multiple languages for the content" feature from the "multiple languages for the Primerpedia interface itself" feature. For the former, it should suffice to present a UI control to select / input a language name or code (controllable via a URL parameter, like the search field). For the latter, setting up translation on translatewiki would be the ideal approach, yes, rather than rolling out our own translation system in this repo.

That said, if we do save a config file in this repo for the few strings that would need to be translated, I suspect we'd have a much quicker path to getting a functional multi-language site off the ground, and the translatewiki setup could be done later without wasting work since the existing translations could be imported.

So my proposal for this would be to first do the content language selection, then the interface translation using a local setup, and only later on look into translatewiki integration. If that sounds good to you, I'd open separate issues for each of these steps, to provide more granularity in the tracking.

[Jan-Ka]

Yes, this sounds perfect.

Please create the dedicated issues :)

[waldyrious]

Done: #46 and #47.

[waldyrious]

Fixed in #60.

_This task was completed during the Wikimedia Hackathon 2019. The associated Phabricator task is T223849._

[waldyrious]

Huh. For some reason I forgot to actually close the issue.