Update crowdin dependency

[JimMadge]

From package.json it looks like the source for the crowdin CLI is a jar in website/crowdin/. This hasn't been updated in a number of years. I see that there is a crowdin NPM package, which seems like a sensible replacement.

[flpm]

I will take a look into this as I work with the translations.

I found the JAR file releases in github but it would be much nicer to have it in an NPM package.

[flpm]

Yeah, the current client is too old and does not seem to work anymore:

❯ java -jar website/crowdin/crowdin-cli.jar --config crowdin.yaml download
ERROR
code: 2
message: Version 1.0 of the Crowdin API has been deprecated and removed

[lwasser]

@flpm, I just opened #891 because that is definitely what is breaking Netlify. I'm not trying to step on your toes, but just wanted to update that dep, and then I can re-create a master branch to see if things deploy without error.

[flpm]

@lwasser No worries! Unfortunately just updating the client is not enough :( both the command-line options and the config file format have changed. I have a version of the config that works locally on my machine, but uses a different method to pass in the credentials. I have to try using the same ENV variables that are set in the current Netlify build environment to see if I can make that work.

We could work on getting CrowdIn working on the current version of the site in order to restore translations quickly, assuming:

• we have a way to deploy to the current Netlify
• the credentials set in the build environment are still valid to authenticate to CrowdIn

Do we have any access to see how the build environment is set up in Netlify? i.e. environment variable names, etc.

[lwasser]

Ok - I should have contained my excitement about finding the broken build message.

There are a few moving pieces here but I suggested a path forward here after a short email exchange with Jake (who owns the netlify team) and jim!

The short take:
🚫 We don't have access to Netlify
🚫 I think getting access is complicated, as teams is a paid feature.

• If we want to use Netlify for deployment, I suggest we create our own team. I already started the process of applying for a free open source team! 🎉
• We should stay on course and use our limited time to get the astro site with translations working on GitHub pages (for now)- rather than trying to duct tape the live site because old dependencies are icky (a technical term 😆 ).
• Jake can redirect the domain name to that url and take down their netlify project.
• If/when Netlify approves our open source site, we can revisit deployment there.

I think setting up GitHub Pages here is straightforward and will give us the control we need to keep moving forward successfully and iron out any kinks in the build. And astro seems awesome so far - very flexible!

I'm sorry for once again confusing things. There are still a few moving pieces, but I think the plan above ensures that the moving pieces don't impact our progress 🪴 .

[flpm]

Moving later from GH pages to Netlify would be easy, so I think this plan makes sense. It does not close any doors and there is a lot of work that has to be done no matter where the site ends up.

I will work next on integrating CrowdIn with Astro and will investigate what are the options for front-end redirects so we can send a user to their language directly. We can evaluate the UX and then make the decision.

[lwasser]

Awesome!! I'm really glad we are on the same page!! I do think, just given some of the account constraints that we have now (that are very fixable!), it makes sense to do this.

Let's focus on this comment here, next ... the goal: organize all of the tasks associated with the docs and open subtask/issues. We can flag some as help-wanted too in case others can help. This will help us organize and also help others see what we're working on and what issues need help!!