Skip to content

Test translation tooling for localizations #45756

@a-mccarthy

Description

@a-mccarthy

Breaking out from #45175 and #45209, this issue focuses on forming a team to test out different TLMP tools for use to localize Kubernetes docs, including creating a prototype. Special thanks to @sftim for help reviewing the testing plan/requirements.

If you would like to participate, please respond by Monday, April 22nd with your interest.

Outcomes of the testing phase:

During this testing phase we'd like to identify the technical requirements necessary to integrate a TLMP such as Transifex or Crowdin into this kubernetes/website repository.

At the end of the phase we should have:

  • a working proof of concept that is accessible to the community and highlights localization workflows
  • detailed documentation outlining the findings of this testing, including:
    • Use cases/workflows tested
    • Tooling implementation requirements
    • Long term support requirements
    • (Protoype) testing team’s recommendation on tooling
  • (if applicable) evidence that the tooling evaluated isn't suitable and that there are insoluble barriers to adoption
    (unlikely, but this is a valid outcome even if it's not what we want)
  • a presentation to SIG Docs during a community call on the findings of this testing

Testing phase timeline

To be determined, depends on finding volunteers to help do the testing.

  • Volunteer deadline: April 22, 2024
  • Estimated testing phase length: 30 days
  • Kickoff meeting date: To be determined, based on availability of volunteers
  • Testing period:
    • Start date: MM-DD-YYYY
    • End Date: MM-DD-YYYY

Resources

To do the testing we'd like the following roles filled with folks from the community. The testing phase will last about 1 month and has light some time requires depending on the role you'd like to help out with (described below).

Volunteers for this testing should be is able to

  1. read/write a language other than English
  2. has some experience with our current localizing and reviewing processes
  3. commit to helping for the entire testing phase. You wont necessarily have work for the entire time, but we'd ask that volunteers can commit to be responsive on slack and GitHub for the testing phase.
  4. Volunteers should also be Kubernetes Github Org members.

If you have experience with these tools already, great! But you do not need to know anything about the tooling to be a volunteer here, having a new users experience is very valuable for our testing.

We'd also be interested in having a whole language team, or part of a team, participate in the testing. That way we'd be able to test the whole workflow, from localizing content, reviewing it, and "publishing" it.

Roles

TLMP administrator: We need two (or more) people to look after the prototype TLMP and either shut it down at the end of the prototype phase, or update it for adoption. The two person minimum comes from not wanting to rely on any single contributor; we could otherwise end up in a situation where we have a platform we can't manage. These contributors may also join a Google Group or similar, associated with the TLMP's owner identity.

  • Needed: two contributors

  • Time Commitment: 30 minutes - 1 hour per week split between the 2 admins (about 3 hours total during the testing phase)

    1. [NAME - github]
    2. [NAME - github]

Communication Lead: We need one person to lead communication for the testing. They will help share progress and highlight blockers for the testing teams. This person should be available to attend SIG meetings for sharing updates to SIG docs

  • Needed: one contributor

  • Time Commitment: 30 minutes to 1 hour per week (about 3 hours total during the testing phase)

    1. [NAME - github]

Technical lead: We should involve one of the SIG's technical leads as liaison and to either contribute to the report to the SIG, or to review it. The person should also be available to answer questions during the testing phase

  • Needed: One technical lead
  • Time commitment: 3 hours minimum over the course of the testing phase
  1. [NAME - github]

Localization team: To make sure we are testing the workflows completely, we'd like to make sure we have testers and reviewers from the same language. We ask that volunteers for these roles sign up from the same localization team, and fill the roles for their specific language. There should be TLMP testers and localization reviewers for each language that chooses to participate.

  • TLMP testers: People who'll try using the localization management platform to localize documentation.
    • Needed: at least two people, but ideally more.
    • Time Commitment: Two hours each minimum - over 30 days. Testers may want to spend more time testing, but we are asking that testers can spend at least 2 hours localizing within the tools.
  • Localization reviewers: Reviewers able to review in the same language as the testers.
    • Needed: at least two reviewers from each localization team. We'll want to find out what the experience is like for reviewers, and we'd like to see more than one change get all the way to publication.
      *Time commitment: Minimum time commitment is about 1 hour over the testing phase.

Note: Ideally, testers and reviewers within a localization team are different people, which models how the localization workflow work now.

[Language] Team:

TLMP testers:

  1. [NAME - github]
  2. [NAME - github]

Localization reviewers:

  1. [NAME - github]
  2. [NAME - github]

Non goals

  • Directly adopt a translation management platform without trialling it
  • Force all localization teams to use or try a TLMP
  • Address all identified issues during the prototype phase

/area localization

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/localizationGeneral issues or PRs related to localizationkind/featureCategorizes issue or PR as related to a new feature.lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.needs-triageIndicates an issue or PR lacks a `triage/foo` label and requires one.priority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to complete.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions