Closed gilgongo closed 1 week ago
I'll look into it when I get some time. Shouldn't be too hard, just a bit tedious.
BTW I see these codes also turn up in our sitemap.xml (which is I suppose where Google is mainly seeing them). If the root cause turns out to be too difficult, could we hack it there with a substitution? EDIT: Nope. GitHub Pages don't allow user plugins.
See also this related issue.
I think this problem seems to come from something that po4a-create-all-targets.sh
is doing with $lang
. At least, I can fix it manually my re-naming stuff, but running the script sets it back again (and breaks it).
@gilgongo are you also re-naming the folders in _translator-files/po/
? That's where $lang
gets the language codes from.
@gilgongo are you also re-naming the folders in
_translator-files/po/
? That's where$lang
gets the language codes from.
Ah yes, but I confused myself with the symlinks in the next-release branch. I think I've sorted it now but need to check.
Yeah, there's the "1-xx-index.md" files, the folders in /assets/img/
and _translator-files/po/
, a regex that needs to be changed in /.github/workflows/add-lang.yml
(line 21, change the underscore to a -), and then the language code in all the po files for the languages where it's changed. Oh, and the relevant line in _config.yml
. I think that's it but there may be more. I'm not sure how Weblate will react too, but we'll get to that.
@ignotus666 OK so now that all seems to be working on my local machine (and I did a link check just in case), does this need to go to release or next-release? I've got a branch on my fork made from next-release (which seems to have some commits relating to the symlinks I'm changing?)
I'd say it should go to next-release.
Closing as now incorporated in https://github.com/jamulussoftware/jamuluswebsite/pull/993
The Google SEO report for jamulus.io says there is a problem with "unknown language codes" in some links using the "hreflang" property. This is used in the language switcher, specifically zh_CN, nb_NO, ko_KR, pt_BR, pt_PT.
It seems that if we can change the UI to show for example "zh-CN" and not "zh_CN", that would fix it.
I don't know how much of a problem this is for displaying content in the relevant Google geographic regions though, but it may be worth fixing.
PS: Google is probably picking it up from sitemap.xml in fact. See my comment below.