search

Spittal / vue-i18n-extract

Manage vue-i18n localization with static analysis
https://pixari.github.io/vue-i18n-extract/#what-is-it
MIT License
313 stars 86 forks source link

feat: add outputOrder option #169

Closed kleinfreund closed 1 year ago

kleinfreund commented 2 years ago

feat: add outputOrder option

Adds a new optional config and CLI option outputOrder which when set to 'lexical' sorts reports and language files (when using the add option) alphabetically. By default, the option is set to 'append' which represents the current behavior of appending new translation keys to a language file when using the add option.

fix: persist new line at end of language file

Fixes an issue with a new line at the end of a language file not being persisted.

Intends to implement #112.

kleinfreund commented 2 years ago

I think this should only be merged once https://github.com/Spittal/vue-i18n-extract/pull/170 is merged (or a similar commit was pushed). Then, I would rebase this PR and include a commit with the rebuilt distribution files to avoid the same issue for this PR’s feature.

Spittal commented 2 years ago

I'll rebuild and version control the new build files before I publish.

Spittal commented 2 years ago

Before I merge this, I actually think that Lexical should be the default sort? Right? I'm of the opinion that we shouldn't add too many options. The scope of the project should be pretty small.

What is your opinion @kleinfreund ?

Spittal commented 2 years ago

Another thing worth mentioning to, I've been thinking about removing the --ci option and making the tool by default return proper exit codes. I can't think of a situation where you wouldn't want that.

kleinfreund commented 2 years ago

I’ve rebased the PR and updated the readme according to my recent changes to the configuration documentation.

Before I merge this, I actually think that Lexical should be the default sort?

Personally, I tend to agree. For the sake of not introducing a breaking change, however, I would prefer to add lexical sorting as an option and consider changing the default in a separate release with a breaking change released as a major version. Currently, I also don’t see a need for more options other than the two named in this PR. Being able to choose between the two would at least allow existing users to keep the established behavior even in the event of the library electing lexical sorting as a new default.

Another thing worth mentioning to, I've been thinking about removing the --ci option and making the tool by default return proper exit codes. I can't think of a situation where you wouldn't want that.

I don’t have a particularly strong opinion on this, but personally, I also don’t see a big value in the ci option. I think its current behavior leaves some room for discussion with regards to what scenario should actually result in a non-zero exit code. I can imagine that it might make sense to people to have a non-zero exit code for missing translations but perhaps not for unused ones. I know that at work, our workflow deals with unused translations asynchronously and we only care about missing keys in CI.