search

fabianmichael / kirby-meta

All-in-one solution to all of your SEO/OpenGraph/JSON-LD needs. 👀
MIT License
65 stars 8 forks source link

Add links to alternative languages, meta locale, OpenGraph locale #26

Open fabianmichael opened 1 year ago

fabianmichael commented 1 year ago

E.g.

See

There needs to be an API/hook to filter out incomplete versions of secondary languages, so they can also be removed from the XML sitemap.

Daandelange commented 1 year ago

After reading some more docs, regarding the og:locale:alternate, I doubt its usefulness. Some people are wondering if Facebook still uses them, and if still used, you're supposed to listen for ?fb_locale=fr_FR when the server pings back (requires adding a kirby route-->url-rewrite?), and you need to serve the corresponding translation. Otherwise this tag doesn't seem to do anything, plus it feels weird to indicate that a content translation is available without serving its URL.

og:locale still seems useful to indicate the content language and it's already present.
Note that it currently serves a language code, not a locale. (fr instead of fr_FR).

fabianmichael commented 1 year ago

@Daandelange Let’s omit the OpenGraph stuff then and just add the alternate meta tags.

Daandelange commented 1 year ago

Tree commits :

  1. The base functionality (tested in multilang with-and-without languages.detect).
    Untranslated content is not served as "alternate".
    x-default is set according to languages.detect or to english with a fallback to the default language. image

  2. Custom lang switcher url setting.

  3. Send content-language in HTTP-Headers too. image

I'm not sure you'd want them all, haha. (you can pick just one)

fabianmichael commented 1 year ago

@Daandelange Thas already looks like a great start, thank you! :-) My only concern is, that most of the logic is contained within the snippet. I’d prefer to have all of that within the PageMeta class and just handle the HTML-generating part within the snippet. That said, using <link>s is probably the most transparent way of serving this to the client and will also work better with https://github.com/getkirby/staticache on cheap hosting.

We also need to ensure, that we got the same implementation for generating the links in the Sitemap (see https://github.com/fabianmichael/kirby-meta/blob/main/src/Sitemap.php#L87-L97). Like I mentioned earlier, in some of my project I got additional options for disabling languages or translations of single pages in the panel. I also got a project, where translations of news articles are generated automatically by DeepL and just stored in the cache. On that project, the translated content does never exist, even if a translation of a page exists. Another example: Let’s say I got a page called "Blog", that does not have any content on it’s own. The title "Blog" works for many languages, so most translations of that page might never be created. TL;DR: Using $page->translation($lang->code())->exists() is quite smart, but I see many pitfalls/edge cases where it would fail.

I think having something like a $pageMeta->translations() method that fires a hook, e.g. meta.translations:after would be the best way for supporting all possible scenarios. What do you think?

Daandelange commented 1 year ago

Thanks for these explanations, didn't think about such scenarios. (in scenario 1 $virtualPage->translation() could/should be implemented in such scenarios, no ?) Anyways, that makes perfectly sense to me, let's go for it.

Daandelange commented 1 year ago

Hey, I'm almost there but there's a choice to make first.

How to access/share $pageMeta->alternateLanguages() for usage within Sitemap->urlsForPage() ? Maybe alternateLanguages() shouldn't be in PageMeta and not be <link rel...> oriented ?

Also, I've rather opted for meta.alternateLanguages:after & $pageMeta->alternateLanguages() to avoid confusion with content translations and be more explicit.

fabianmichael commented 1 year ago

How to access/share $pageMeta->alternateLanguages() for usage within Sitemap->urlsForPage() ? Maybe alternateLanguages() shouldn't be in PageMeta and not be oriented ?

Does anything speak against accessing PageMeta->alternateLanguages()from a Sitemap-method?

I like the idea of defining the method in more abstract form, so it could easily be used in different scenarios.