-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update app translations – Localizable.strings
#18200
Closed
Closed
Conversation
This file contains 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
A leftover of the previous way we did `.strings` extraction from the file downloaded from GlotPress into the `InfoPlist.strings` and app extension `.strings` files. Notice that the `WordPressIntents` app extension which the variable referred to is part of the `MANUALLY_MAINTAINED_STRINGS_FILES` `Hash` which we pass to current iteration of the extractor action.
Since we need to do the process in two steps, therefore have two commits, we also need a way to differentiate between the `Localizable.strings` commit and the "other `.strings`" one.
The previous version used `Dir.glob('**/*.txt', base: metadata_directory)`, but that didn't work for two reasons. First, even if we use `base:`, the paths returned by `glob` are still relative. From the docs: > The optional base keyword argument specifies the base directory for > interpreting relative pathnames instead of the current working > directory. As the results are not prefixed with the base directory name > in this case, you will need to prepend the base directory name if you > want real paths. See https://ruby-doc.org/core-2.7.4/Dir.html#method-c-glob . Second, `Dir.glob` returns the files that match the given pattern, but that excludes _deleted_ files. If a file is not there anymore, it can't match the given pattern. This would have made the commit incomplete. We could argue whether our code should delete the existing translations when it doesn't find new ones. Even if we concluded that behavior is not desirable, we'd still need to account for it locally until we update it in the release toolkit. Otherwise, our local copies would remain dirty after downloading the release notes metadata if no new ones are available.
Generated by 🚫 dangerJS |
AliSoftware
force-pushed
the
release/19.5-localization-commit-fixes
branch
from
March 24, 2022 17:59
2e3dbf0
to
9c557da
Compare
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.
No description provided.