I think you can add this command to the Makefile.

Can you move the tool totools directory? It fits better there.

Also maybe add a conveniencemake target for it.

1. I believe it can be optimized to finish in a few seconds (at most)
2. It still lacks the ability to check missing keys likeTr("the.key.is.missing.in.locale")
3. We need to declare these non-static keys at the place where they are used, but not make a tool to "know everything"
4. We should never introduce any new top-level single-word keys likeTr("error"), it is unsearchable and make it impossible to maintain.

We should never introduce any new top-level single-word keys like Tr("error"), it is unsearchable and make it impossible to maintain.

I disagree, sometimes you have simple words to translate, and top-level is ideal for them. Unsearchability is a tooling issue.

I believe it can be optimized to finish in a few seconds (at most)

Yes, I suppose this is because it serially walks the files while such a operation could and should be parallelized (maybe with limited concurrency to stay within OS open file number limits).

We should never introduce any new top-level single-word keys like Tr("error"), it is unsearchable and make it impossible to maintain.

I disagree, sometimes you have simple words to translate, and top-level is ideal for them. Unsearchability is a tooling issue.

It's impossible to build a correct tool to resolve the "tooling issue". If you think yes, please show a feasible solution.

I believe it can be optimized to finish in a few seconds (at most)

Yes, I suppose this is because it serially walks the files while such a operation could and should be parallelized (maybe with limited concurrency to stay within OS open file number limits).

I think it's purely a algorithm problem, no parallelization is needed ......

I believe it can be optimized to finish in a few seconds (at most)

Yes, I suppose this is because it serially walks the files while such a operation could and should be parallelized (maybe with limited concurrency to stay within OS open file number limits).

I think it's purely a algorithm problem, no parallelization is needed ......

Yeah, I was just refering tofilepath.WalkDir which is presumably a serial operation, but likely still fast enough.

We should never introduce any new top-level single-word keys like Tr("error"), it is unsearchable and make it impossible to maintain.

I disagree, sometimes you have simple words to translate, and top-level is ideal for them. Unsearchability is a tooling issue.

It's impossible to build a correct tool to resolve the "tooling issue". If you think yes, please show a feasible solution.

Could introduce a prefix to all translations liketr-error which makes the strings greppable viatr-error\b for example.

I skimmed through this and if I'm understanding correctly it's looking through all files for each key.
Why not inverse this and collect used keys first, then compare them with the list?

something similar in shell (fish but I don't think any specific syntax from it is used). bare in mind it probably is missing keys as it's a quick PoC.

rg"TrN?\"([\w._]*)\""-o--no-filename--no-line-number-r'$1'>keys#find all Tr(N)s from templatesrg"Tr?N\(\"(.*)\"\)"-o--no-filename--no-line-number-r'$1'>> keys# find all Tr(N)s from go filessort keys|uniq> keys_in_code# sort for comparisonrg"(.*) = .*" options/locale/locale_en-US.ini-N-r'$1'|sort|uniq> keys_in_locale# strip to keys and sortcomm keys_in_locale keys_in_code-32# list every key in locale which wasn't in code

Disregard - this does not take locale being in ini format so it's wrong.

I skimmed through this and if I'm understanding correctly it's looking through all files for each key.
Why not inverse this and collect used keys first, then compare them with the list?

The challenge is like this:

key := "k1"if ... {    key = "k2"}ctx.Locale.Tr(key)

Ah. True, that complicates things.

Can you move the tool totools directory? It fits better there.

Also maybe add a conveniencemake target for it.

Another locale tool, backport-locale, is located under the build directory. Therefore, I think it makes sense to keep them together. How about moving the entire build directory under tools, as tools/build?

OK. I pushed a commit. Now it will take about 15s so that I also introduced it in CI for pull request.

1. I believe it can be optimized to finish in a few seconds (at most)

improve, now it's about 15s.

2. It still lacks the ability to check missing keys likeTr("the.key.is.missing.in.locale")

Yes. This tool just check unused keys but not check missed keys.

3. We need to declare these non-static keys at the place where they are used, but not make a tool to "know everything"
4. We should never introduce any new top-level single-word keys likeTr("error"), it is unsearchable and make it impossible to maintain.

Still would like the script moved totools directory.build is for build-related scripts only.

#34737 (comment)

Still I think it needs to address 2 & 3