-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Comprehensive reorganization of localization file #6521
base: master
Are you sure you want to change the base?
Conversation
|
The review will be fun, but this is a really good idea thanks for tackling this! I love "better engineering" PRs like this one 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would you think of adding a character to split namespace and key? IepackageResolver/incorrectLockfileEntry
instead of packageResolverIncorrectLockfileEntry
. I think that would help readability
@@ -210,7 +210,7 @@ export default class Git implements GitRefResolvingInterface { | |||
if (await Git.repoExists(secureRef)) { | |||
return secureRef; | |||
} else { | |||
reporter.warn(reporter.lang('downloadHTTPWithoutCommit', ref.repository)); | |||
reporter.warn(reporter.lang('getDownloadHttpWithoutCommit', ref.repository)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be gitDownloadHttpWithoutCommit
(rather than get
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I will update.
Summary
I was doing some work on a feature and a saw how unorganized the localization file was. Not only does it make it a crap shoot for where to put a new string (if you even feel like doing it), it also makes it really difficult to approach translating into a new language at all. To that end, I made my best effort to organize the strings. I have grouped them by command (using common and core for things that don't relate to a specific command) alphabetized the groups, and alphabetized the strings within the groups. I also added a header to explain the organization within the file.
This will make the file much cleaner and more maintainable. It also makes it easy to catch people not adding strings in the right place during code review.
I do understand this will be a pain for a little bit because it will cause a number of merge conflicts. I feel that the organization and maintenance gains will make it worth it, though.
Test plan
If the tests pass, this should be good. I am not intentionally changing any functionality.