Internationalizing lib.reviews through TWN

Internationalizing lib.reviews through TWN

Hi folks,

I'm the maintainer of a free/open software platform for reviews, called lib.reviews. We're currently in invite-only mode, but invites are available for the asking. The software is under CC-0 (the used libraries are under various other open source licenses), the review content is CC-BY-SA and the metadata for items to be reviewed is under CC-0. For more on the terms of the platform see: https://lib.reviews/terms

I've tried to develop with i18n in mind from the beginning, and there's currently a German version alongside the English one. I use the i18n package for Node.js. By default that package encourages the use of messages-as-keys, but I'm following the convention of separating keys and messages. The package supports multiple plural forms using CLDR conventions, as implemented by its make-plural dependency.

The message files are in JSON format, found here. As you can see there's already a complete qqq file for message documentation. I also use the README page to document translation conventions.

A couple of people have already offered to work on translations and I'd love to point them to the translatewiki.net platform for it. In addition, any help from the TWN community would be very much appreciated. You can read a bit more about the motivation behind this project here.

Are there any obvious blockers for using TWN for internationalization, and if not, could you advise me on next steps? :)

Eloquence (talk)21:20, 30 August 2016

This all sounds very nice! One note: is it possible to use UTF-8 encoding? I am seeing html entities in the German translation.

Nike (talk)10:07, 1 September 2016

That was just me being lazy (umlauts are annoying to type on a US keyboard); I just converted them. I just double-checked that all content is served as UTF-8 including API responses and Atom feeds.

Eloquence (talk)12:40, 1 September 2016

Nikerabbit: Checking in (& hope you're feeling better!) -- anything else I can do right now to help move this along?

Eloquence (talk)11:00, 13 September 2016

I'm recovering. Quick note: consider using Unicode CLDR for language names to avoid repetition in their translation. Oh, and what about RTL languages?

Other than that, it is on my queue for new project addition which is again backlogged. For that you can already start preparing the basic information:

  • Project name
  • Logo (optional, svg preferred)
  • Project page in Translating namespace
  • Short description that will be placed in Group_descriptions.
  • GitHub push access for me and Siebrand
Nike (talk)07:40, 14 September 2016

That's a good point re: CLDR. I've filed a bug for that and will get to that shortly.

Re: right-to-left-support, what I'd suggest is: 1) Once we get any RTL translation, I will add the basic LTR/RTL directionality markers alongside activating it. That part, I think, is relatively straightforward. 2) I will, however, need help from an actual speaker of the language, such as a translator, to verify that everything is done correctly, and to identify additional issues to resolve. Does that approach seem reasonable?

Here's the requested info:

  • Project name: lib.reviews
  • Logo: File:Libreviews.svg
  • Project page: Translating:lib.reviews
  • Description: "A free, open, not-for-profit website for reviewing absolutely anything"
  • GitHub access: Should be done, added you and Siebrand via the "collaborators" interface of the repository
Eloquence (talk)10:07, 14 September 2016
 

We now use the CLDR for language names, as well.

Eloquence (talk)08:53, 25 September 2016

Per discussion with Niklas I'll see if I can follow the documentation he just added at New project setup to do most of this myself.

Eloquence (talk)21:11, 29 September 2016