Project translations: Laying the foundations
As there have been multiple attempts to translate this project, I think it's time to create a single point of reference on this topic.
Right now, there are/were multiple translations online based on the old switching.social:
- German: https://swiso.de/ - by me, unmaintained
- French: https://switching.geber.ga/ - by @albakham (https://miaou.drycat.fr/@albakham)
- Italian: https://switching.ml - seems to be down (?)
- Turkish: https://www.sosyaldegisim.com/ - having certificate issues, last update a year ago
Furthermore, there was some development inside of this project repo:
- German: issue #29 developed on language/german
- French: issue #20 developed on language/french
- Brazilian Portuguese: issue #97
As of today, there is no complete translation that I'm aware of. Some reasons I can think of:
- Sheer size: This site is quite large by now, despite its simple homepage.
- Translation means Adaption: In my opinion, translating this project also means adapting the order of the entries - and even the choice of entries itself - to the target audience. Most software is available in English, but many lack other translations, so can't really be recommended for beginners.
- Adaption means Discussion: If you change something, there should be a way to discuss these changes - preferable in the associated language.
- Commitment: It's easy to start translating/maintaining a project, but it's hard to keep it up to date.
For these reasons, I stopped working on the German version to focus on the English version. And I realised, that I can't offer a lot of support on maintaining a translation - besides basic setup of technical stuff. See #60 for my inability to find additional time for this 😅
I have no feature-complete solution for this, only a handful of thoughts open for discussion:
- Separate issue lists: I think a translation of any kind will sooner or later (I bet sooner) have its own language-specific issues to deal with. Based on my "Adaption" point further up, I also think, that translations will want to focus on different things than the English version. How-to support software translations, helping with English buzzwords, country-specific issues, ... or simply discussing issues in the related language instead of English. I don't want to exclude these and other discussions here, but I think it will restrain the translation efforts if we try to keep them contained in this issue tracker and force them to be in English.
- Separate repositories: Well, based on seperate issue lists, I come to this conclusion: Forking. I know this sounds scary at least, but I think if we keep them on Codeberg and bundled in the swiso organization this could work really nice in my opinion. We can really get into discussions on language-specific things there. This also eases the onboarding for new contributors, as they only have to deal with their language of choice. And to minimize the disadvantages of separation ...
- Publish together: ... we can join the translations by a common build pipeline. Maybe by separate folders in the same Hugo project. Maybe by separate Hugo projects with a common theme. We can deployed on the same server with different sub-domains or with language-specific domains. All backed by Drone.io and Hugo.
- Moderation and Commitment: These are important ones for me. I think, there should be at least one person per language, that takes responsibility for the associated repository, its content and the resulting web pages. Even if the discussions on the related issue tracker continued in English, I can't moderate the content itself. But if we publish together, we need someone or somegroup per language we can trust on this. Seperate repositories make it easy to organise these responsibilities - branches and issues in the same repository won't do the trick in my opinion.
So far so good on my thoughts on this. I just wrote this down in one take and really need to get some rest now after work today 😂 As you see by the length of this, I really want us to move ahead on translations. But I fear we won't succeed with language branches like we have them now 😅
Please let me know what you think on all of this! Where do you disagree? What could be done differently? What are your concerns and thoughts on this?
Maybe by separate folders in the same Hugo project.
This can be accomplished by
git submodules. There's an argument for having the softwarey-type stuff (i.e. templates, the deploy script) in a separate repository anyway, keeping the data / content version controlled in a different place, with different control systems, etc.. Deploying typos in prose has drastically different effects to deploying typos in the deploy script!
Plus, that'd let us separate issues like 84 and 86 from issues like 93 and 95.
Deleting a branch is permanent. It CANNOT be undone. Continue?