Incorrect lang attribute on Resources page

[emersonthis]

Bug:
We noticed this exact same problem on the homepage: #284
The language buttons work but the page's lang attribute does not change from en. This matters because CSS needs this to know how to correctly format accents, etc for certain languages (like Greek).

Suggested fix:
We solved this exact issue on the homepage in this PR: #297 . I suspect the identical refactor needs to happen for the resources page:

• create a new file for each translation with the corresponding language suffix (ex: resources-it.md)
• Update the yaml at the top of each version of the file to include the correct lang value (ex: 'it') and also the title value should be in the same language if we want the html <title> to be translated.

[rousik]

Note that we don't localize Resources pages so it's always in English, which means that we can expect to see mixed-language pages here.

Do you know what's the right approach in such situation?

[emersonthis]

I should think about this more, but my first quick thought is that we should use the yaml attributes at the top of each resource entry to specify the language, then set the lang attribute accordingly on each entry. That we could have an entry that’s for Greece, written in Greek, and we won’t have typography problems. Another option is to just write all the resources in English since they’re mostly external links anyway. If we’re resolved not to localize this page, this may be the best answer.

…

On Apr 24, 2020, at 11:11 AM, Jan Rous ***@***.***> wrote:  Note that we don't localize Resources pages so it's always in English, which means that we can expect to see mixed-language pages here. Do you know what's the right approach in such situation? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[rousik]

The entries are all in English as of today.

…

On Fri, Apr 24, 2020, 13:06 emersonthis ***@***.***> wrote: I should think about this more, but my first quick thought is that we should use the yaml attributes at the top of each resource entry to specify the language, then set the lang attribute accordingly on each entry. That we could have an entry that’s for Greece, written in Greek, and we won’t have typography problems. Another option is to just write all the resources in English since they’re mostly external links anyway. If we’re resolved not to localize this page, this may be the best answer. > On Apr 24, 2020, at 11:11 AM, Jan Rous ***@***.***> wrote: > >  > Note that we don't localize Resources pages so it's always in English, which means that we can expect to see mixed-language pages here. > > Do you know what's the right approach in such situation? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or unsubscribe. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#304 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABYSCGAMPTDGLM54FESDV53ROHPLRANCNFSM4MBGZV4Q> .

[rousik]

I don't think we have mechanism in place to translate these and no plans to translate them as of today so we can assume that the page will be in English, possibly with the header/intro section translated? It seems technically feasible to translate these but I'm not sure if it's worth our energy and possibly limited translation bandwidth to focus on that. So until things change, let's assume this is always English.

…

On Fri, Apr 24, 2020, 13:08 Jan Rouš ***@***.***> wrote: The entries are all in English as of today. On Fri, Apr 24, 2020, 13:06 emersonthis ***@***.***> wrote: > I should think about this more, but my first quick thought is that we > should use the yaml attributes at the top of each resource entry to specify > the language, then set the lang attribute accordingly on each entry. That > we could have an entry that’s for Greece, written in Greek, and we won’t > have typography problems. > > Another option is to just write all the resources in English since > they’re mostly external links anyway. If we’re resolved not to localize > this page, this may be the best answer. > > > On Apr 24, 2020, at 11:11 AM, Jan Rous ***@***.***> > wrote: > > > >  > > Note that we don't localize Resources pages so it's always in English, > which means that we can expect to see mixed-language pages here. > > > > Do you know what's the right approach in such situation? > > > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub, or unsubscribe. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#304 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABYSCGAMPTDGLM54FESDV53ROHPLRANCNFSM4MBGZV4Q> > . >

[emersonthis]

I still think we need to fix the lang attribute on the HTML tag so that the menu works correctly for all languages. But maybe we just wrap the main content in a lang=en-us and be done with it.

…

On Apr 24, 2020, at 12:08 PM, Jan Rous ***@***.***> wrote:  The entries are all in English as of today. On Fri, Apr 24, 2020, 13:06 emersonthis ***@***.***> wrote: > I should think about this more, but my first quick thought is that we > should use the yaml attributes at the top of each resource entry to specify > the language, then set the lang attribute accordingly on each entry. That > we could have an entry that’s for Greece, written in Greek, and we won’t > have typography problems. > > Another option is to just write all the resources in English since they’re > mostly external links anyway. If we’re resolved not to localize this page, > this may be the best answer. > > > On Apr 24, 2020, at 11:11 AM, Jan Rous ***@***.***> wrote: > > > >  > > Note that we don't localize Resources pages so it's always in English, > which means that we can expect to see mixed-language pages here. > > > > Do you know what's the right approach in such situation? > > > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub, or unsubscribe. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#304 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABYSCGAMPTDGLM54FESDV53ROHPLRANCNFSM4MBGZV4Q> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.