docs(Translations): configure astro to build translations and setup language redirects

[lwasser]

Translation setup part two (part 1 is here)

• Configure Astro to build translations (drop-down on the site is automatically added)
• Set up redirection to the user's language (this seems easy to do by adding a meta redirect to the landing page)

[lwasser]

This could be broken into two smaller issues potentially !

[flpm]

UPDATE: I have been working on this task, but it is taking a little longer than expected because of some conflicts between the CrowdIn and Astro behaviors.

Astro needs the locale folders (translated files) to be next to the original English source files, but placing them there causes CrowdIn to see them as part of the English source and upload them to the site for translation. There are a few options to resolve this issue but I am still working out the pros and cons of each approach.

[lwasser]

Eeks, oh, that is hard. Let me know if I can be helpful in any way @flpm !!

[JimMadge]

Set up redirection to the user's language (this seems easy to do by adding a meta redirect to the landing page)

@lwasser is there documentation for this?

[flpm]

I did some more research as I was working on the integration of CrowdIn and Astro, it is possible but it has some disadvantages that makes me reconsider:

• Search engines don't like it, which might affect how the site is indexed and could make it harder to find.
• The way I managed to get a proof of concept going required to move the English source into a locale folder, which then changes the URLs and would break links that point into the all-contributors site.

I think we should keep the server side redirects open as an option. I did some quick research and noticed that Vercel also offers an option to create server side redirects. Could be something to explore if Netlify does not work out.

[JimMadge]

The thing I don't understand is, I think redirects are returned by the webserver. On Netlify, you have the option to define redirects in your configuration. That way it supports redirects without given people access to the underlying software. I don't think GitHub pages has that feature, and I'm not sure if there is anything we can do in HTML/JS to replace/replicate it.

I think I'm just worried we go down a road assuming redirects will work only to find later it isn't possible.

[flpm]

Ah, got it.

There are two strategies to redirect the user to another URL in the browser side.

1. Using a meta HTML tag in the header. Here are more details about meta tag redirects

2. Using JavaScript to change the location.href More details here

In order to redirect to a language page we would need to use option 2 combined with something to detect the language, for example this

Those are not HTTP 3XX redirect responses, like you said, those can only be created by the server.

[flpm]

I think we can always move the site to Netlify (or similar) and set redirects there. We would only need to set the CI to publish to that location instead of GitHub pages, all the rest would be the same.

[lwasser]

@flpm i have a question and then a comment. I've been migrating pages to MDX format, and I read that Crowdin supports that format. But I realized I hadn't communicated that with you. The absolute worst-case scenario is that we move back to MD, but MDX provides some really nice features like automagically converting images to webp and avif that are useful for both accessibility, performance, and maintenance.

In terms of Netlify, we could redirect our efforts, but let's revisit the plan and why we are moving in this direction.

We landed on GitHub pages as a quick way to get the website back online with minimal additional or external work. And no account setup.

Right now, we have a domain that is routed to Netlify, but we've

• modified the master branch --> main, and we can't access Netlify settings. And we don't have access to the DNS for the domain.

To get a new Netlify account, I applied! I can add the Netlify badge to the live site so we get approved, but then we need Jake to redirect the site to the new Netlify account, and Jake was more interested in moving to GitHub Pages. And I wanted to focus my time on the docs as they are so close. So I'm doing things one at a time.

My concern about the domain is that we have to decide whether we want to pay for the domain or not. I thought we could make that decision later (Jake is open to transferring it to us, but we'd have to pay for a renewal if we do that).

The simplest path forward seemed to be:

1. get the site live on GitHub Pages (we literally could do that now!) in English only. The site builds - i'm just adding image compression and fixing links here and there.
2. In the meantime, Felipe works on translations and what we need to do to make them work with Astro and whatever platform we decide to commit to.
3. We also want to host translations here on GitHub, so that is another task that is important, regardless of the platform that we land on.
4. Get the Netlify badge on the new site and get the OSS license for that account. Netlify will indeed offer server-side redirects - that is nice!! I would presume we'd do some sort of front-end browser-side redirect for transactions otherwise?
5. I would own the Netlify account, but we can figure out access together - maybe we can create a Google group or something for access? I don't want to be the only admin, as that leads to the space we are in now in the future if I am offline for any period of time unexpectedly!
   So my goal is really just to get a proof of concept with Astro Live here for our users.
   Then do the work and make decisions around DNS, Netlify, etc! The only work that we might not use in all of this is the GitHub action we co-developed, but that was easy to create, so I won't cry if we move to Netlify (that rhymed!) 😆 dev opsy stuff is always fun.

I'm super open to an alternative path, but this one feels direct to me. If another plan sounds better to you all, let's chat about it!! Perhaps Thursday morning?