Translation of feedback messages
TwilightCoder opened this issue · 17 comments
What is the standard approach for translating the feedback messages? Apart from forking and editing the source file lib/zxcvbn/feedback.rb.
Also, are PR submissions accepted for this? We prefer the gettext syntax, although I18n would work too (although a new gem dependency is apparently required in both cases).
P.S. Thanks for this ruby port.
All the work done so far was to make this tool as compatible as possible with the dropbox's one as possible. Their work did not include any translation, either.
I have noticed other people with similar problems (like here: envato/zxcvbn-ruby#36) but I could not get any feedback from them. Just trying to avoid guessing the solution.
I would be aiming for leaving the existing api shared with zxcvbn-ruby and zxcvbn-js untouched, meaning the #test method would still work the same way. And add another method that returns translatable information (or translated).
IMHO, I think if just the translatable information (translation key and values) is returned, then the developer can easily integrate with their translation tool of choice.
I can't remember from the top of my head but I believe there may be more files involved than just feedback.rb. It may have the most of it, but I guess it is not everything.
-edit-
I took a quick look and I believe the other piece would be the method ::display_time on time_estimates.rb and I think that's all.
-end edit-
Of course PR's may be accepted. I will be glad to have any kind of help. 😄
@TwilightCoder I just noticed something that might be helpful: None of the feedback strings have interpolation, which makes their translation trivial. just _(string) them away and translate them.
The ::display_time ones are the only that have interpolation going but that is also a simple function of number of guesses required to crack a password, which is also provided in the result. Not very hard to implement.
I believe that having a full list of string that will need translation documented anywhere will be the hardest part of this work in any way you decide to tackle it.
This is the list with all strings I could find.
suggestions:
"Use a few words, avoid common phrases"
"No need for symbols, digits, or uppercase letters"
"Add another word or two. Uncommon words are better."
"Use a longer keyboard pattern with more turns"
"Avoid repeated words and characters"
"Avoid sequences"
"Avoid recent years"
"Avoid years that are associated with you"
"Avoid dates and years that are associated with you"
"Capitalization doesn't help very much"
"All-uppercase is almost as easy to guess as all-lowercase"
"Reversed words aren't much harder to guess"
"Predictable substitutions like '@' instead of 'a' don't help very much"
warnings:
"Straight rows of keys are easy to guess"
"Short keyboard patterns are easy to guess"
'Repeats like "aaa" are easy to guess'
'Repeats like "abcabcabc" are only slightly harder to guess than "abc"'
"Sequences like abc or 6543 are easy to guess"
"Recent years are easy to guess"
"Dates are often easy to guess"
"This is a top-10 common password"
"This is a top-100 common password"
"This is a very common password"
"This is similar to a commonly used password"
"A word by itself is easy to guess" if is_sole_match
"Names and surnames by themselves are easy to guess"
"Common names and surnames are easy to guess"
time_estimates: # with pluralization depending on `base`
"less than a second"
"#{base} second"
"#{base} minute"
"#{base} hour"
"#{base} day"
"#{base} month"
"#{base} year"
"centuries"
None of the feedback strings have interpolation, which makes their translation trivial. just _(string) them away and translate them.
Yes, I realized this alternative approach later and was going with it. I did similarly extract those strings from feedback.rb and put them as comments wrapped in n_() for the gettext parser. Still, it's useful for confirmation.
We aren't using the ::display_time currently, so that makes it simpler too.
IMHO, I think if just the translatable information (translation key and values) is returned, then the developer can easily integrate with their translation tool of choice.
Returning the keys here along with the value might be helpful for I18n syntax, but I don't see it making things any easier for gettext syntax. And even for the I18n syntax, I see a sample repo above that seems to handle it somewhat eloquently by converting sentences into keys by snake casing them (references: code | locale file).
Thanks for the digging and writeup.
I think gettext can work fine with keys similar to i18n, it is just not the convention (https://phrase.com/blog/posts/i18n-translate-ruby-applications-with-gettext-gem/#:~:text=Here%2C%20as%20you,New%20account%20instantiated!%22).
Actually, after having a closer look on how gettext would manage these translations plus after seeing what that link you have posted above on how they managed to use i18n, I have a stronger feeling that this gem should not (or need not) try to tackle translations because it is not hard at all to pick any tool and adapt to do the job.
It could be done even using a simple hash and mappings.
Having that said, I think this discussion was really valid and its contents will still be useful. mainly the strings that would be translated: #4 (comment)
I believe something (else) still need to be done with all the information we got here, what I am not sure is if it there should be another gem to depend on this one to add the translations on it, or another repo with the source for translations or even just a wiki entry with some explanation on how to achieve that.
I don't have a clear use-case to implement and help me to drive this atm but I would love to point to such work.
I think gettext can work fine with keys similar to i18n, it is just not the convention
Good to know, although that seems to negate most of the benefits of using gettext over i18n.
I have a stronger feeling that this gem should not (or need not) try to tackle translations because it is not hard at all to pick any tool and adapt to do the job.
Yes, this is what I was implying as well.
I believe something (else) still need to be done with all the information we got here [...]
Having a wiki entry (linked in the readme) seems sufficient for now.
I agree and with the little time I had in hand today I could only make this: https://github.com/formigarafa/zxcvbn-rb/wiki/Translations
Hopefully, soon I will extend it and link in the readme. Please, feel free to suggest changes and supply examples using gettext, I don't feel I am the best for this last one.
added link on readme and also more explanations on the process.
Looks good mostly.
Regarding gettext:
Gettext implementations are even more straight forward using their _(string) method.
Additionally (as noted above), it's worth mentioning that the source messages should be manually listed somewhere in a sync path, wrapped in a gettext method (ideally N_()) for it to be picked up during sync, for eg:
# list of hardcoded source texts from the gem for the gettext parser
# N_("Straight rows of keys are easy to guess")
# N_("Short keyboard patterns are easy to guess")
# ...
translated_warning = _(zxcvbn_result.feedback['warning'])@TwilightCoder , if you don't mind I would really appreciate if you could add these details for me on the wiki and I believe you will do a better job than me. thanks.
Should've mentioned this earlier, but - sorry, I don't have permission to edit the wiki page.
ooooohhhh!!!! just found the setting that makes wiki publicly editable, @TwilightCoder .
I (wrongly) assumed it would default to public or have some sort of moderation in place.
Well, learned something new.
Please, have a go now. thanks.
Done!
just found the setting that makes wiki publicly editable
Although not sure how much of a desirable state this is.
that's great the way it is and if for any reason someone find something to be improved the door is open for it and every help is welcome.
thanks.
if for any reason someone find something to be improved the door is open for it and every help is welcome.
No doubt. Although my concern was more about (the possibility of) unwanted edits.
So far I don't believe any person will come to cause trouble.
And we have history on that wiki, so it is easier to revert than to create problem. I will keep an eye on it.