opral / inlang-paraglide-js

Tree-shakable i18n library build on the inlang ecosystem.
https://inlang.com/m/gerre34r/library-inlang-paraglideJs
42 stars 0 forks source link

Default language does not get prerendered in SvelteKit #66

Open pago93 opened 6 months ago

pago93 commented 6 months ago

When setting export const prerender = true; in +layout.ts no files for the optional default languages get created with @sveltejs/adapter-static.

I've got these default settings for inlang:

{
  "$schema": "https://inlang.com/schema/project-settings",
  "sourceLanguageTag": "en",
  "languageTags": [
    "en",
    "de"
  ],
  "modules": [
    "https://cdn.jsdelivr.net/npm/@inlang/message-lint-rule-empty-pattern@latest/dist/index.js",
    "https://cdn.jsdelivr.net/npm/@inlang/message-lint-rule-missing-translation@latest/dist/index.js",
    "https://cdn.jsdelivr.net/npm/@inlang/message-lint-rule-without-source@latest/dist/index.js",
    "https://cdn.jsdelivr.net/npm/@inlang/message-lint-rule-valid-js-identifier@latest/dist/index.js",
    "https://cdn.jsdelivr.net/npm/@inlang/plugin-message-format@latest/dist/index.js",
    "https://cdn.jsdelivr.net/npm/@inlang/plugin-m-function-matcher@latest/dist/index.js"
  ],
  "plugin.inlang.messageFormat": {
    "pathPattern": "./messages/{languageTag}.json"
  }
}

I would have expected to see these folders after build:

index.html (default language)
de\index.html
en\index.html

But the there isn't even a en folder created. Therefore prerendering for the default language only works if accessing https:\\my-site\ and not via https:\\my-site\en.

LorisSigrist commented 6 months ago

The default behavior is that the default language is created without a prefix. This is so that accessing / on prerendered pages still returns something.

However, I understand that you would probably want there to still be something on /[defaultLanguage]. What behavior would you expect:

I'm quite partial to the first option, as that would open the door for other kinds of language-detection

pago93 commented 5 months ago

For adapter static I would have expected the second option (prerendering both). It does come at a cost of duplicated files on the server, but I would expect it to be the best option performance wise.

I am fine with option one too. There may be some break-even point between an additional roundtrip to the server to get the prerendered page vs just serving the fallback page at this point. I am no SEO Expert but there might be considerations regardings this too. Ideally if there could be a switch between both ways in some kind of options, everyone can optimize for their own scenario.

Option 3 seems to only shift the problem in another way. So I don't see any benefits from it.

LorisSigrist commented 5 months ago

My concern with option 2 is that it's difficult to tell search-engines about alternate versions of the page, since the page now exists in two places.

Option 1 seems like a more reasonable default.

LorisSigrist commented 5 months ago

Seems like option 2 is what other people expect as well. I'll see how I can handle this. https://twitter.com/loris_sigrist/status/1777635207304069196

Perhaps we can tell search engines that / has the language x-default, which is the canonical way of saying it's the default language. Perhaps a canonical tag is necessary as well