#98 Project translations: Laying the foundations

Open
opened 4 months ago by brickup · 2 comments
brickup commented 4 months ago

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.

Status quo

Right now, there are/were multiple translations online based on the old switching.social:

Furthermore, there was some development inside of this project repo:

Obstacles

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 😅

Proposal

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.

Feedback pleeeease!

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?

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. ### Status quo 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](https://codeberg.org/swiso/website/src/branch/language/german) * French: issue #20 developed on [language/french](https://codeberg.org/swiso/website/src/branch/language/french) * Brazilian Portuguese: issue #97 ### Obstacles 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 😅 ### Proposal 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](https://codeberg.org/swiso) 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](https://gohugo.io/content-management/multilingual/#translation-by-content-directory) in the same Hugo project. Maybe by separate Hugo projects with a common [theme](https://gohugo.io/hugo-modules/theme-components). 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. ### Feedback pleeeease! 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?
brickup added the
discussion
label 4 months ago
brickup added the
feedback needed
label 4 months ago
brickup added the
translation
label 4 months ago
brickup added a new dependency 4 months ago
brickup removed a dependency 4 months ago
brickup added a new dependency 4 months ago
brickup added a new dependency 4 months ago
brickup added a new dependency 4 months ago
wizzwizz4 commented 4 months ago
Collaborator

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.

> 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.
Jelv commented 1 month ago

When the foundations are done I would like to help out with the Dutch version.

When the foundations are done I would like to help out with the Dutch version.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Blocks
#97 PT-BR translation
swiso/website
#29 German version
swiso/website
#20 French version
swiso/website
Loading…
There is no content yet.