Open zhouhanseng opened 4 years ago
we may be need a unused locale name scanner tools.
I found global search is quite enough now. Here I realize flat key style is made for global search, which differs from nested key style. So I think we can make a rule:
t('add_token')
✅
t('add' + '_' + 'token')
❌Is this way feasible?
locale name need strongly typing check and so 2nd issue does not exist
@zhouhanseng if you can, you can solve this issue?
write a script, scan out all unused locale name.
@septs Sure, I like this idea, I will do it.
I would like to suggest that the same line of all locale files should represent the same locale key, so that each locale key can be mapped to a specific (autoincrementl) integer. This will be helpful for cross-file comparison, especially when the keys are many enough.
The key is strongly typed so only allows whole key reference.
We also need a tool to warn about missing key in zh or jp(en is the baseline).
I think we should use i18n with namespace to lead a faultless global search. Liket('messages.about_dialog_description')
Currently some key names are so common, could be used at other place. e.g.
// messages.json
{
"browse": "Browse…"
}
Here string 'browse' maybe used for process.env
or some other place, so findTextInFileGlobally('browser')
is unsafe, findTextInFileGlobally('namespace.browser')
is much better.
Second, pattern findTextInFileGlobally("t('browser')")
is also unsafe, if we write code like this:
const keyName = 'about_dialog_description'
t(keyName)
// or (this exists)
t('additional_post_box__steganography_post_pre', { random: String(Date.now()) })
Currently, I just use t('some_key'
as the pattern to do global search in my script.
Good idea. We also need to split namespaces for the locale files (CC @septs )
Please let me just add the namespace 'messages' first, yet I have done the research of supporting namespace for ally-i18n. After that. Let's remove unused locale keys (total 98). Finally splitting namespaces.
I found some locales key-value are unused(out-of-date?), I think it's better to remove them from _locales. It is chiefly in this that for adding new language, we can avoid unnecessary translation.