Hello,
Are there any plans to translate the website into other languages?
There are few texts today, I can easily offer you a French translation.
Ideally, going through Transifex, but I don’t know what is already in place in terms of the structure of the website.
Thank you for your work and for your time!
Francois
Thanks for offering your help!
I don’t know what is already in place in terms of the structure of the website.
Currently only the general texts (main page, etc) can be translated. The blog posts and the documentation cannot be translated because keeping the translations up-to-date and not having conflicting information would be hard to do there.
I’m not 100% sure yet if we really want to have the website translations on Transifex. The reason is that these need special care (wording should be considered more carefully than in the app). However, we also have the Google Play description on Transifex, so maybe it actually is okay to put them there. What do you think, @keunes?
Actually I think it’s fine to have everything on Transifex, though I’m wondering if we (before connecting the site with Transifex) should look into moving to another (open source) platform as discussed in another thread. (Don’t know how much effort it is to connect the site with Transifex?)
As for what to translate: I believe we said everything (incl documentation) except the blog posts. Documentation shouldn’t change too often, hopefully.
Hmm, the documentation currently does not seem to be translatable
I’m still not really convinced. It risks losing translators and does not really have advantages. The good (and bad) thing about large platforms is that that’s where the people are.
Transifex can read the main yaml translation file directly. The pages need to be added as individual resources, which could get pretty cluttered (and a bit of work). I don’t think other translation services have better support for translating a whole folder of text files. That also means that whenever a new markdown file is created, we need manual action to register the file with the translation service. Feels like it kind of destroys the advantages of automatically creating pages from markdown files.
If there really is no way to have all pages in a single resource, we probably need to use another project inside the organization anyway (otherwise the actual app will get lost between hundreds of website resources). Maybe we could do the website on another service and keep the app on Transifex.
That could be a nice middle ground. It seems that neither pontoon nor weblate can directly handle MD files. Weblate has support for simple text files in beta, however. A README file is given as an example, which is often in MD, so it might work.
From an SO question it seems that new items can be created in Weblate automatically if new (site) content is added. But it seems that it’s still best to transform MD files to PO files first. Would be great if that could be automised in a GitHub action, but couldn’t find any hints or marketplace item for this.
Oh nice, that’s exactly what I was looking for 
Sounds like we would then need to have two versions of each file in the repo. That’s not really clean
Just found https://mdpo.readthedocs.io which can create PO files from MD files.
Ideally multiple MD files are combined into a single PO file. E.g. one for Home, one for Documentation, one for Contribute, and one for About. Not sure that’s easy though. Quickly had a look at the mdpo docs but didn’t see a way to combine multiple MD files into one po file.
That would also help keep clean the translation tool; one Website project with four (section-based) resources.
What happens with the existing translations when the source file changes? Does that tool create po keys that are somehow reproducible?
Wouldn’t it be better to translate one documentation page as a whole instead of paragraph-by-paragraph? Makes it more consistent.
Since PO keys seem to be the source text, I don’t think keys are consistent throughout time. But that shouldn’t be a problem because the tools have a translation memory, and should normally suggest an old translation if there was a minor change.
What do you mean with ‘as a whole’ - as one single ‘string’? (I wouldn’t want that as it’d be one massive text that is hard to translate and hard to spot errors in.)
At most I’d say we can have one string per category, but it sounds complicated to make that happen.
OK, that should work then
OK
Okay, so every time someone changes the translations, we would need a CI task that creates a second commit that re-creates the PO files?
I think so yeah, or in any case the POT files (which only contain the source strings).
Hmm, that clutters the commit history so much 
More than every second commit would then be an automated one. Additionally, Weblate creates a bunch of commits (see Commits · Etar-Group/Etar-Calendar · GitHub for example). Makes it very hard to see what the actual changes are and what’s just noise.
Transifex does handle markdown files directly.
I don’t think a cluttered git history is a big a problem as with the app, because it’s a much more simple (& stabl) codebase.
Weblate credits the translator for their work, rather than taking credit itself 
To limit history clutter we could have a dedicated translations branch, where once in a while we manually commit changes to main (e.g. when all languages are updated after a site change).
Update: mdpo can create a single PO file from multiple MD files: Multiple MD files in one PO file · Issue #169 · mondeja/mdpo · GitHub
Okay, do you want to look into setting this up? I would suggest to use 3 resources:
_i18n/en.yml)_i18n/en/*.md)Due to Bring back arm/v7 images · Issue #968 · WeblateOrg/docker · GitHub I’m not able to build Weblate on my RPi and Pontoon Docker throws an error as well (and is not intended for production anyway). I’m now trying to set up translations using hosted weblate (on my fork of the website). Let’s see how this goes 
I think using the hosted version is better anyways because we do not need to maintain it and translators already have an account
Bon, I’m stuck for the moment: Cannot push translations: "Fork creation failed: not found" · WeblateOrg/weblate · Discussion #6763 · GitHub
For Weblate yes - but if we could’ve run Pontoon easily I would’ve preferred that given its Translator interface.
@Kusco Just to give you an update: I’m trying to optimise the website for translations, and prepare some automation (so that when new website texts are added, they show up in the translations tool). It might take another week or two to complete it, but I’ll announce it here when the system is ready for translations. Thanks for putting this in motion!
No problem @keunes, I followed the whole conversation (I studied computer science).
Thank you for your time and for your work. I’ll be happy to participate when the time is right 