Repository navigation
Classify localization folders by name, not by the whole path - #30
Merged
Merged
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
biodranik
force-pushed
the
ab/language-folder-classification
branch
from
August 21, 2026 18:53
7c4be35 to
085e783
Compare
Member
Author
|
Rebased onto #31, which fixes the pre-existing Ruff findings described above, so this now targets The only conflict was the import block in |
This comment was marked as resolved.
This comment was marked as resolved.
biodranik
force-pushed
the
ab/language-folder-classification
branch
from
August 21, 2026 19:46
085e783 to
d9d0344
Compare
determine_language_given_path() falls back to scanning every path segment for
something matching ^[a-z]{2,3}(-[A-Za-z]{2,4})?$, and the two directory scans
handed it the joined absolute path of each candidate folder. Any short
lowercase ancestor of the repository matches: /tmp, /var, /opt, /home/ab. A
checkout under such a path made every non-language subfolder of an output
directory look like a language, so generate-all-localization-files wrote
into it.
With --include all (Apple, jQuery) that produced whole English files in
source folders; with --include translated (Android) the output was empty and
silently skipped, which only hid the same misclassification. It also made the
generated output depend on where the repository happens to live.
generate_all_localization_files and find_translation_files both iterate the
direct children of one directory, so the language can only come from the
child's own name. They now ask language_for_folder_name for it. The Apple and
Android formatters override it to accept only <lang>.lproj and values[-lang],
which is what folders named "raw" or "xml" were relying on not being checked.
determine_language_given_path itself is untouched, because it is also reached
from _prepare_read_write with a path the user named, where a missing language
silently falls back to the developer language: tightening it there would make
`consume-localization-file de.strings --format apple` import German as
English.
Mirrored in lib/twine so both implementations agree.
Signed-off-by: Alexander Borsuk <me@alex.bio>
biodranik
force-pushed
the
ab/language-folder-classification
branch
from
August 22, 2026 16:18
d9d0344 to
18b63ed
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
determine_language_given_path()falls back to scanning every segment of the path it is given for^[a-z]{2,3}(-[A-Za-z]{2,4})?$, andgenerate_all_localization_files()handed it the joined absolute path of each candidate folder. Any short lowercase ancestor of the checkout matches:So every non-language subfolder of an output directory was treated as a language. With
--include allthat wrote full English files into source folders; with--include translatedthe output was empty and silently skipped, which only hid the same misclassification. Worst of all, generated output depended on where the repository happened to be cloned.Both
generate_all_localization_files()andfind_translation_files()iterate the direct children of a single directory, so the language can only come from the child's own name — ancestors are meaningless there. Pass the name instead._prepare_read_write()is left alone: it receives an arbitrary file path such as…/en.lproj/Localizable.strings, where the segment walk is the point.That alone still left folders named
rawandxmlmatching. Formatters with a fixed convention now returnNonerather than falling back to the generic regex: an Apple localization folder is always<lang>.lproj, an Android one alwaysvalues[-lang].The same flaw is in
lib/twine/runner.rb; changed there too for parity.Testing
Running organicmaps'
tools/unix/generate_localizations.shfrom a checkout under/private/tmp, against a clean tree:The 672 legitimate files are byte-identical to what is checked in, and a second run is idempotent.
pytest: 134 passed, including two new regression tests. One drives the runner through aTemporaryDirectory, which reproduces the original bug naturally — macOS temp dirs live under/var/folders.