Translation Organization at Transifex

[lidel]

TL;DR

Q: What happens when i18n efforts grow bigger and cover more than IPFS? A: ?

Background

Right now we have IPFS Org at https://www.transifex.com/ipfs/public/ with the community of over 50+ translators.

In the past weeks other projects such as IPLD, libp2p, Filecoin reached out and mentioned interest in enabling translation of CLI/GUI tools, documentation and websites at some point in the future.

We also have more and more video materials from events hosted by Protocol Labs that could get captioning. The topic range of those spans across all PL endeavors and is tricky to put them in a specific box.

Overall, projects, communities and teams grow and we should have a strategy ready when some of them decide to join translation efforts.

To bootstrap the discussion, I wrote some notes and described three simple strategies below.

Requirements

• We need a strategy on how to organize translation efforts, especially ones based on Transifex tool
  • Should we have one Transifex Org or multiple ones?
  • Will the decision be the same for "IPFS, IPLD and libp2p" vs "Protocol Labs" and "Filecoin"?
  • Which ones will be based on crowdsourcing and which ones will simply order translations?
• How can we future-proof reuse of translations via Translation Memory and actively take advantage of Shared Memory Groups to reuse translations across related projects (eg. share IPFS-related memory across ipfs-companion and ipfs-webui)
  • Note: Shared Memory Groups are a paid feature that Protocol Labs is sponsoring right now for IPFS Org.
• Bonus Question: should we form "i18n Working Group" within PL?

Strategy A (Use IPFS Org as i18n "incubator")

• Keep IPFS, IPLD and libp2p and others under IPFS Org for now and define rules on when it makes sense to "split"
  • ✔️ Re-use existing subscription for paid features
  • ✔️ Re-use engagement: 50+ translators get notified about new strings to translate
  • ✔️ We can always move specific projects to separate Orgs in the future
  • Decision on when to split could be "project wants to translate more than one sub-project"
  • ⭕ It may be bit confusing when we have things like translations of http://libp2p.io under IPFS org.
  • ⭕ We may decide to break the "incubator" strategy for some projects anyway. For example having transifex.com/ipfs/go-filecoin will be very confusing ("so how do I mine IPFS?").
  • ⭕ Some translators will miss the "split/move" event, which will hurt the engagement

Strategy B (Create separate Orgs from the beginning)

• Create separate orgs for PL, IPFS, IPLD and libp2p etc and split paid plan across all of them
  • ✔️ Re-use existing subscription for paid features (confirmed with Transifex we can share single plan for multiple orgs)
  • ✔️ Less "noise"
  • clear separation from the start
  • separate communities are easier to manage in the long run, each org and project having own DRI
  • ✔️ Better control over quality of translations
    • eg. Filecoin may choose to order paid translations instead of crowdsourcing
  • ❓ No translation sharing (re-use) between projects from different orgs (this can be a feature tho)
  • ❓ Lower engagement in the due to separate translation teams and increased friction (could also be a feature, if we want to prioritize quality over quantity eg. for Filecoin)
  • ⭕ Makes access to paid features more complicated, we need to manually adjust limits, re-negotiate with Transifex or buy a separate plan

Strategy C (Consolidate everything under a single Org)

• Basically the same as A, but we don't plan to have any separate Orgs. The idea is to rename "IPFS" Org to "Protocol Labs", making it project-agnostic. It would enable us to keep everything under a single Org, eg. transifex.com/protocol-labs/ipfs-companion, protocol-labs/libp2p.io or protocol-labs/go-filecoin

  • ✔️ Single paid plan, simple to set up, bit harder to manage

  • ✔️ We can have multiple Memory Groups across all PL endeavors

  • projects that use IPLD, libp2p and ipfs could share translations, and each set could have different projects

  • ❓ Re-use engagement: 50+ translators get notified about new strings to translate

  • ⭕ More "noise" eg. most of Filecoin folks may not care about IPLD

  • ❓ We can decide to have a single translation team, or multiple ones, (eg. separate one for Filecoin), but when its just "Strategy B" with more noise

  • ⭕ Huge org looks intimidating, and "Protocol Labs" (commercial entity) branding may discourage people from contributing translations to IPFS (open source project)

  • ⭕ Use of company name may not sit well with some folks

    • ..but as long PL is sponsoring paid features on Transifex, it is easy to explain

---

I probably skipped a lot of nuance, but it should be a good conversation starter.

While Strategy (A) and (C) could work for libp2p, IPLD or Multiformats, for Filecoin we want to have separate organization on Transifex from the start (Strategy B). Separate Org provides better control over quality of translations. I confirmed with Transifex we are able to share paid plan across multiple orgs, or use free versions / separate plans if we choose to do so.

Feedback would be very much appreciated.

cc'd some of stakeholders: @olizilla @diasdavid @doctorrobinson @jesseclay @mikeal @pkafei @terichadbourne @michellebrous @mishmosh

[lidel]

For the record, we went with Strategy B (Create separate Orgs from the beginning)

• https://www.transifex.com/ipfs/
• https://www.transifex.com/filecoin/ (private for now)