Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • T tails
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 971
    • Issues 971
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 24
    • Merge requests 24
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • tails
  • tails
  • Issues
  • #16095
Closed
Open
Issue created Nov 04, 2018 by sajolida@sajolidaMaintainer1 of 1 checklist item completed1/1 checklist item

Curate the list of languages in Tails Greeter

Originally created by @sajolida on #16095 (Redmine)

We currently have many languages or languages variants that are poorly or not translated at all (either in Debian and GNOME in general or for our internal tools). It’s the case for example of “Chinese, mandarin” and probably many others.

Having such a long list makes it harder to know which languages are actually well translated and for the user to know what’s her best option is, without trial and errors.

I think we should filter this list to only display the languages that are reasonably well translated.

Implementation-wise, the Greeter can do either:

  • A. Only propose languages that have a PO file in tails.git + tier-1 languages, period. This embeds a removal mechanism, by definition.
  • B. Propose languages that have a PO file in tails.git + tier-1 languages + any language that was proposed in our last release. And then, manually clean up “any language that was proposed in our last release” from time to time.
  • C. Same as B except we automate the cleaning process as intrigeri suggested in #16095 (comment 18701)

Option A is the cheapest and is probably good enough. If we notice trouble later (e.g. churn/flapping, i.e. languages appearing and disappearing every second release), we can come back to it and implement option B or C.

Then, we’ll need to remove all language packs (e.g. Tor Browser’s) that can’t possibly be used (because they’re not listed in the Greeter).

Feature Branch: https://salsa.debian.org/tails-team/tails/merge_requests/39/commits

Attachments

  • languages.ods

Related issues

  • Related to #16093 (closed)
  • Related to #14544 (closed)
  • Related to #15807 (closed)
  • Related to #9956 (closed)
  • Related to #7036 (closed)
  • Related to #17002 (closed)
  • Related to #17089 (closed)
  • Related to #16774 (closed)
  • Related to #17139 (closed)
  • Blocks #16688 (closed)
  • Blocks #16094 (closed)
  • Blocks #16806 (closed)
  • Blocks #17058 (closed)
  • Blocks #17087 (closed)
  • Blocks #13447 (closed)
  • Blocks #17089 (closed)
  • Blocked by #17106 (closed)
Edited May 21, 2020 by sajolida
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking