Article translations

[svinkle]

In the spirit of inclusivity, I've been thinking about offering the content here on A11YProject in other languages. In order to do so, there are some questions to be answered:

1. How easy/difficult would it be to setup navigation for translated articles? Would there be a global nav language toggle, or perhaps a per-article sub navigation (thinking if a translation exists, offer links along the top of the article.)

2. We' need to find translators. At first we could ask the greater community for help, though if this doesn't work out, does anyone have experience with translation services?

3. Is this within or out of scope of A11YProject? Is this too ambitious?

What do people think of this? I think it would be really great to at least have the architecture setup to allow the option for someone to contribute a piece in another language.

[nschonni]

There is https://github.com/Anthony-Gaudino/jekyll-multiple-languages-plugin, but it's not one of the plug-ins whitelisted by GitHub (AFAIK)
You could also try the manual way like https://github.com/wet-boew/wet-boew-jekyll

[svinkle]

@jeryj, familiar with any of the links @nschonni mentioned above? Any other thoughts around setting something like this up?

[jeryj]

@svinkle Nope. I haven't used Jekyll for that many projects, so my experience with extending it is fairly limited. Given GitHub Page's plugin limitation, the architecture will probably be frustrating to set-up. I do think it's a good idea if we can figure out a way to implement a system that allows for translations and simple maintenance.

For question #1, I like how https://github.com/Anthony-Gaudino/jekyll-multiple-languages-plugin builds an entirely different site so one could see all the articles in a certain language, but it may also mean their language's site only has one article. My ideal would be a way to allow for both global and on the article translation, but I'm not sure how we'd link everything up so that each article knows about its translated siblings.

[nschonni]

PS, there is also a discussion on what plug-in to whitelist github/pages-gem#401

[alexcarpenter]

I know Hugo's Sass Guidelines makes use of translations. https://github.com/HugoGiraudel/sass-guidelines

[Gutem]

I can translate some to pt_BR

[HugoPalomares]

I would be happy to help with some es_MX translations.

…

On Oct 2, 2017 11:43 PM, "Gutem" ***@***.***> wrote: I can translate some to pt_BR — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#511 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE2pImnAsHht917vvuvwn9du6ka3kMW-ks5soa14gaJpZM4O-CUo> .

[svinkle]

@Gutem @HugoPalomares Thanks for your interest in contributing! As things are at the moment, we still don't have a solution for serving translated articles.

That said, we can still accept PRs in the form of translations and place them in a language specific folder until we have the infrastructure available.

Here are some articles I think would be good to start with:

• Quick Tip: A11y and a brief numeronyms primer
• Getting Started with OS X VoiceOver
• Getting started with ARIA

Here's how I'd like the flow to happen:

1. Pick just one of the articles linked above to translate
2. When you have something ready, place it in gist and link to it in a new issue where the project maintainers can review
3. If things are all good, create a PR with the post content and set the file as: _posts/[lang]/yyyy-mm-dd-post-title.md.

Thanks and let me know if you have any questions! 🙂

[dhcodes]

@jeryj I got a couple of things in the pipeline but down the road, you and I should work on this.

[jeryj]

@dhcodes Sounds good! Let's figure out what the good options are when we have some time to collaborate.

[svinkle]

So, just realized there's a Google translate thing in the footer. I mean, I knew it was there, but hadn't put two and two together and, well, maybe we don't need to pursue this feature? It seems to do the job…

Although, the accessibility of it is very poor. Perhaps we could try and fix it a bit via JS?

[pkra]

The Google translation into German is rather poor. So while procrastinating, I started writing a German translation as a test - I used the post on numeronyms. Draft at https://gist.github.com/pkra/ebba8c7142dd79bd61e500a6487576ee

I'd be happy to get feedback and corrections; I'm a native speaker but I might be too much in an English bubble for work to get German a11y lingo right. Happy to do more translations if that's still interesting.

[svinkle]

@pkra This is awesome! Unfortunately we still need to come up with a solution to handle translated articles. Once that's solved, we'll be able to publish. Vielen Dank! 🙂

[pkra]

@svinkle no worries at all. This was just a test run. Perhaps it's simpler to grab a11yprojekt.de
etc?

[ValorNaram]

Well, it doesn't seem a problem to me to make it to work without using external software.

You just have to create a folder lang in the root of this repo and you place all subfolders with their translated articles inside. Since you have defined a standard, linking to them should be not the problem.

Folder structure can be the following:

./
../
_data
_layouts
_posts
_sass
css
lang
   de
       ueber
   es
   fr
   rus

So you can add a link to the german equivalent of https://a11yproject.com/about pointing to https://a11yproject.com/lang/de/ueber.

It's handwork, but good to have

Good issue 👍

[svinkle]

Would there be a way to set the URL structure as https://a11yproject.com/de/ueber?

[ValorNaram]

First part

Well yes, if you look into this repo you see the file about.md, click on it to view its content. You see its content is the same as the content at https://a11yproject.com/about, because its the same resource and the same page. If you edit about.md in the repo, you will edit the site on https://a11yproject.com/about too. This repo is the website at https://a11yproject.com/ itself.

Second part

Method 1

Ok, let me explain further what I try to tell you: For that we edit the file about.md

Accessibility can be a complex and difficult topic. The Accessibility Project understands this and wants to help make it easier to implement on the web. Our goal is to accomplish this with three principles in mind:
....
....
....
If you're looking for the german version, then click [here](https://a11yproject.com/lang/de/ueber)

And we create the site at https://a11yproject.com/de/ueber and put the german translation of https://a11yproject.com/about inside

Method 2 (I personally prefer)

You add a language dropdown to the navigation, so we can put the links to the translated articles inside, the dropdown can look like:

Select language
German
Spain
russish
polish

with markdown links:

Select language
[German](https://a11yproject.com/lang/de)
[Spain](https://a11yproject.com/lang/es)
[russish](https://a11yproject.com/lang/rus)
[polish](https://a11yproject.com/lang/pol)

And in the subpage https://a11yproject.com/lang/de we create the folder _posts like you did it in the root of the page and we put all the german translations of the articles inside /lang/de/_posts. Of course, the same goes for all languages

Third part

Technically tricky sice you're working with GitPage, a little script should do the trick to change language site urls according to the original pages in english or we define in every english page/article whatever a markdown variable, so markdown can compile the urls according to https://daringfireball.net/projects/markdown/syntax#link

Citation from https://daringfireball.net/projects/markdown/syntax#link:

[foo]: http://example.com/  "Optional Title Here"
[foo]: http://example.com/  'Optional Title Here'
[foo]: http://example.com/  (Optional Title Here)

and we can use it like

[foo][]

[ValorNaram]

I looked over your code and I see it's possible to set navigation and with js it is possible to change language urls with an algorithm, but we have to keep the english urls e.g. https://a11yproject.com/de/about instead of https://a11yproject.com/de/ueber.

I can look at your code and can make a pull request, when I have written language support. But we have to discuss about where to position the language select otherwise I would break your layout. I think we can add a li Select language with a submenu (sub ul) and can provide links to languages we support. The change of the href is the job of the js I mentioned above.

[ericwbailey]

Are there options for translation we should be investigating as a criteria for the replatforming?

[isatrio]

Hmm, I've read this a while ago and the last comment was 2 years ago. @davatron5000 gave me a link about this. That's why I propose to forking this repo and start from there. But seems, it's stuck on something. I saw @motchie also not even start the translation on JP. Do I miss something?

[davatron5000]

Howdy everyone! Sorry for showing up to a thread two year late but I was recently asked about translations and have put a tiny bit of thought into it this week.

Due to the switch to Eleventy and Netlify, we can workaround some of the limitations we previously had with Jekyll translations. Looking at the documentation for eleventy-plugin-i18n we could maybe have the intuitive URL structure for a11yproject.com/{{ lang }}/{{ localized_page_slug }}

https://www.npmjs.com/package/eleventy-plugin-i18n

The project structure would change a bit...

/src
  /en
    /pages
      page-one.md
  /es
    /paginas
      pagina-uno.md
  /jp
    /ページ
      ページ第一.md

But this seems manageable. The only RISK is that we've added some features with the redesign (Announcements, Spotlights), but maybe we scope translations to posts/ for right now.

Going back to @svinkle's original questions, I think we can check some things off.

• How easy/difficult would it be to setup navigation for translated articles?
  The i18n plugin should allow us to solve some of the technical stuff.
• We' need to find translators.
  Sounds like people are interested in this thread (es-MX, pt-BR, de-DE)
• Is this too ambitious?

For that last question, since the technical hurdles are more or less solved, I think it the needle has moved towards "This seems possible."

From an Ops perspective, here are some considerations we don't need to know the answers to right now.

1. We'd essentially be running different sites while translations are being created, unless we can find a way to do fallback redirects (which may be supported by the plugin or even Netlify)
2. We'd need to establish a bi-directional "editorial flow" for when articles diverge. Or.. maybe not. Maybe we let locales self-manage content-freshness?

I could probably kick off a branch with a prototype using @pkra translation and we'll know a bit more about how feasible this all is.

[pkra]

👋 I'm still interested in this (incl. adding more translations).

I could probably kick off a branch with a prototype using @pkra translation and we'll know a bit more about how feasible this all is.

Let me know if I should update the gist in some way, @davatron5000 ?

[davatron5000]

@pkra Nope! Should be fine. I'll ping this thread when I have something to look at.

[shawnthompson]

I'm watching this post, as we are doing looking to do the same for our project, a11y.canada.ca, which I based on your project.

I am using a json file setting the locale in each language folder en.json.

Then declaring the translation in the data in _data/header.js. which works good for includes and templates.

Finally calling it in _includes/partials/skipnav.njk using:

{{ skipnav[locale].aboutGovernment }}

We are in discussions on how to deal with pages and posts. I'm wondering if we deal with _src different than the structure in the _site folder. By using the permalink in the front matter.

Can't wait to see what you folks come up with.

Linking to our discussion: Language structure of scr files #56