flathub-infra/frontend

Add Translations

Closed this issue · 13 comments

Would be nice, if translations could be added to the new frontend. This would include 2 things:

  1. The Website itself can be translated. All text, that is from the Website itself can be translated into different languages.

  2. When the AppStream data contains a translation for name, summary description etc. and I user, which has a language that has a translation in the AppStream file, the translation should be displayed instead of the default English one.

I would love to see that, but I remember talking about this at some point on matrix and it seemed like the consens was, that it's not worth it right now. It might also be very weird, if only some are translated and most fallback to english.

I personaly think, the Website should support that. Not everybody speaks English. If someone, who doesn't speak english, looks at a App, he or she will be thankfull, if the description is translated. It shows also, that the App itself is translated. While some Apps, who are translated, doesn't translate theier AppStream, almost no App had a translated AppStream when the App itself is not translated.

It'd be good to look some more at the data here when it comes to apps. We should absolutely build the front end as translatable though, even if we choose not to enable it at the beginning as patching this in to a launched codebase is a bit of a nightmare.

Not sure if it qualifies as a nightmare, it's just going to be boring work :)

I have only experience with Desktop Apps, not Websites, but in my experience, when you make a bigger codebase translateable, you may miss a few strings, so it's better to make everything translateable while writing, even if you don't use it in the end. This saves a lot of work.

The appstream (metainfo/appdata) contains a languages tag that has a percentage of how much the app is translated for each language. The overall issue is that indicator doesn't tell us at all if the the metainfo is marked as translatable or if is translated to X language.

In other words, you will have to check if the the strings in the language exists and hope for the best. Also figuring out how to get the translatable strings out of the metainfo file is not easy to do and not supported by the backend so far neither, thanks xml.

Yeah, I think we should split this conceptually into three problems:

  1. Translate the website copy
  2. Identify if the appstream metadata is translated, display that if relevant
  3. Identify if the app itself is translated and into which languages, display that if relevant

They're all of different levels of difficulty but can help users have confidence if an app will be useful for them (and more importantly 2 and 3 have a lot of backend work to do outside this repo!).

Also the backend might provide strings to the frontend, we'll need to decide whether those are translated in the frontend, or if the frontend should send an Accept-Lang header and have those translated in the backend.

I would think translating in the frontend would be best for those cases, as we need to do that anyway and would have infrastructure for all the other translations. We just would need the backend to provide some kind of unique translation identifier.

Once we know how the frontend will be handling translations we can set the appropriate text from the backend for it to hook from - be that a specific token, or the "plain english" or whatever. Thanks @razzeee

@danielsilverstone-ct there's now a PoC for how I would handle translations. I'm not so sure how it currently would hook into a translation system, due to multiple json files, but other then that it should be fine.

Problem here is, that I don't even know, where we would get translations from, would be reuse gnomes translation infrastructure, would we have our own, could we tag along on somebody elses, etc.

I'm also wondering if that infrastructure can handle fluent translations https://projectfluent.org/

@JakobDev following up on this, we do seem to automatically detect the language to a degree.
For e.g. if you go the the page with accept-language set to de you will end up on the german version of the page now.

https://nextjs.org/docs/advanced-features/i18n-routing#automatic-locale-detection