Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

App sync: opt-in file to leave repository-maintained languages untouched + reduce translators workload

Open
  • Is something wrong?
#1,006 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
68/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
git, shell
Domain
ci-cd, localization

Research direction

Read the branch loop in translations-app/handleAppTranslations.sh around the linked lines, then inspect the existing .tx/backport and .tx/validate conventions. Implement and document the proposed opt-in language file, preserving listed language files from git while leaving apps without the file unchanged; verify the behavior in a workflow run.

Written by the indexing model from the issue text.

Description

Problem

For luflow/attendance I maintain German (de, de_DE) in the repository myself: I write the German strings together with each feature and release roughly weekly. All other languages come from Transifex, and I very much want to keep it that way.

The sync cannot leave a language alone today:

  • New source strings are uploaded (tx push -s) and translations pulled (tx pull -f -a --minimum-perc=5) in the same run, so a string added yesterday is always untranslated in that night's pull and its German disappears from l10n/.
  • .tx/config has no key to exclude a language. Redirecting one via lang_map or trans.<lang> only moves the .po; convert-po-files then produces no file for it, and because of rm -f l10n/*.js l10n/*.json followed by git commit -am the existing files are deleted. I tried this in August and lost all four German files.

Since 10 August I have been working around this with a workflow that restores the four German files after every sync commit. That is a stopgap I would like to get rid of: it adds a second commit to main every night (more than 50 so far), and, as @rakekniven rightly pointed out, translators keep working on German strings for this app that are never shipped. I should have raised this here before building the workaround.

Proposal

An opt-in file next to .tx/config, following the existing .tx/backport and .tx/validate pattern. It lists the languages the repository maintains itself, one per line:

de
de_DE

In the branch loop of translations-app/handleAppTranslations.sh, after the cp and before the git add:

  # Languages the repository maintains itself are taken from git again
  if [ -f '.tx/keep-languages' ]; then
    for lang in $(cat .tx/keep-languages); do
      for ext in js json; do
        rm -f "l10n/$lang.$ext"
        git checkout HEAD -- "l10n/$lang.$ext" 2>/dev/null || true
      done
    done
  fi
  • Apps without the file behave exactly as today.
  • The file is read per branch, so a stable branch without it keeps syncing normally.
  • Nothing changes in the Transifex steps; the listed languages are still pulled, they just do not end up in the commit.

The file name is only a suggestion. I am happy to send the PR, including a paragraph for the developer manual.

Open question: translators' time

The hook fixes the repository side only. German would still be open for translation in Transifex for this resource, and languages can only be removed per project, not per resource.

Transifex has per-language lock tags on strings (locked_de, locked_de_DE, see Preventing Translation Edits), which stop translators from editing those strings in that language. According to that article only admins and project maintainers can add tags, and new strings are not tagged automatically.

  • Could the sync set these tags for the languages listed in the file, right after tx push -s?
  • If not, would someone with maintainer rights be willing to set them, or is there a better way to signal "not needed" to the German team?

If neither is acceptable, I would rather change my side so that the community's German is shipped again and I only fill in strings Transifex does not have yet, than keep wasting translators' time.

cc @nickvergessen @rakekniven

Dominant language
Perl
Stars
46
Forks
38
Avg merge
4d 10h
Merged PRs (30d)
7

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nextcloud/docker-ci

All issues in nextcloud/docker-ci

Similar issues

More Perl issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.