FriendlyCaptcha / friendly-challenge

The widget and docs for the proof of work challenge used in Friendly Captcha. Protect your websites and online services from spam and abuse with Friendly Captcha, a privacy-first anti-bot solution.
https://friendlycaptcha.com
MIT License
415 stars 62 forks source link

i18n support? #9

Closed BrunoCartier closed 1 year ago

BrunoCartier commented 4 years ago

Hello,

Thanks for this refreshing anti-robot solution.

Looking at the code, it seems that the widget is english-only. Do you plan, someday, to make it available in several languages?

gzuidhof commented 4 years ago

Hi Bruno :)

It definitely makes sense for the widget to support multiple languages. There's not that much text in it and none of the text is dynamic, so it should be easy to translate and ship translations without increasing the bundle size much.

Could you help me understand your usecase better? Two questions:

<div class="frc-captcha" data-sitekey="<your sitekey>" data-i18n="en"></div>

A cursory look at the texts we would need to translate:

# Before the widget is started
Anti-Robot Verification
Press to Start

# While the widget is downloading a puzzle (usually only takes a split second)
Fetching challenge..

# While the widget is solving
Verifying you are not a robot..

# Completed
I'm not a robot

# Expired (the puzzle was solved, but then waited say a day without submitting)
Anti-Robot verification expired
Restart

# Error
Verification failed:
Retry
dev-love commented 3 years ago

Hi @BrunoCartier Thanks a lot for your suggestion! 👍 Would @gzuidhof's solution be the right one for you?

ghenadiibatalski commented 3 years ago

Hello @gzuidhof Could we optionally configure the texts via options as an alternative/addition to the data-i18n?

gzuidhof commented 3 years ago

Yes I think that makes sense @ghenadiibatalski, I'll make sure to also add an alternative in the options object.

I haven't started work on this yet. Is this a blocker for you? Then I can prioritize the work.

ghenadiibatalski commented 3 years ago

@gzuidhof we discuss now about the licensing model (self hosted vs. the online service). If the decision made, we will need the translation (possibility) for sure.

dtext commented 3 years ago

Any i18n support would be great. We're thinking about using FriendlyCaptcha in a project for a client and not having i18n is at the very least inconvenient. I would be willing to provide German translations.

dev-love commented 3 years ago

I agree! i18n support makes total sense!

@dtext: What do you think about these translations? Please make some suggestions if you have better ideas for translating the strings!

Before the widget is started

Anti-Robot Verification Press to Start DE: Anti-Roboter-Verifizierung Hier klicken

While the widget is downloading a puzzle (usually only takes a split second)

Fetching challenge.. DE: Herausforderung laden..

While the widget is solving

Verifying you are not a robot.. Suggestion for a friendlier text in EN: Verifying you are human.. DE: Verifizierung, dass Sie ein Mensch sind..

Completed

I'm not a robot Suggestion for a friendlier text in EN: I am human DE: Ich bin ein Mensch

Expired (the puzzle was solved, but then waited say a day without submitting)

Anti-Robot verification expired Restart DE: Verifizierung abgelaufen Erneut starten

Error

Verification failed: Retry DE: Verifizierung fehlgeschlagen Erneut versuchen

Looking forward to your reply! :)

gzuidhof commented 3 years ago

Friendly Captcha now supports localization in version 0.7.0 🎉, pinging @dtext @BrunoCartier for visibility.

Built-in are English, German and Dutch. I hope to add at least French to that, hoping for a contribution by a native speaker :).

There is a data-lang attribute that you can use to set the language, or you can provide a custom translation by using the JS API.

timint commented 1 year ago

I would like to bumb this topic with two aspects.

  1. I think data-lang reinvents the wheel when there is already a lang property. <element lang="language_code"> https://www.w3schools.com/Tags/att_global_lang.asp

  2. Why not default this widget to the lang for the document e.g. <html lang="de"> when there is no other property set? It is uncommon that any other language would be preferred on the page other than the one in the html tag.

gzuidhof commented 1 year ago

These are great points, I have never seen lang="something" on an individual element in the wild (although I never specifically looked for it). I suppose that for 99% of websites it makes sense to have it at the top level like you stated in the second point (<html lang="de">), unless the page has various languages on one page (i.e. with user generated content).

For version two of the widget (which we are developing) we are looking at making a more informed guess (looking at browser headers and perhaps also the html lang attribute) to decide the default language. For backwards compatibility I'm hesitant to change the default behavior in this repository - we really value stability (so that anyone can update the version of their widget without worrying that something changed for the end-user or integration).

What I would propose for the current widget version, is that we add a data-lang="auto", where the widget then looks at the attribute on <html lang="de"> to match it to one of the supported languages. What do you think of that proposal @timint?

gzuidhof commented 1 year ago

If it makes sense for accessibility, the widget itself could set the lang attribute on itself based on the selected language. I'm not sure if that provides any benefit though.

timint commented 1 year ago

@gzuidhof You probably haven't seen it because it is rather used for lingual anomalies. Example below:

<html lang="en">
  <p>How to say good morning in different languages:</p>
  <ul>
    <li>German <span lang="de">Guten Morgen</span><li>
    <li>Swedish <span lang="sv">God morgon</span><li>
  </ul>
</html>

For full backwards compatibility I propose the following:

  1. Use data-lang param.
  2. If missing, look for lang param.
  3. If missing, look for first occurrence of a parent lang param (where html is the last parent).

This way a lang param is inherited down the way html node levels do their job until another node overrides it.

gzuidhof commented 1 year ago

Interesting! Nice to learn something new :)

I like the idea of traversing up to find the first node with the lang attribute.

We'll have to introduce something like data-lang="auto", because otherwise someone who has html lang="de" set on the root of their page will have their widget in a different language after updating to the latest release.

For version two (which will be released this year, hard to put a date on it though as we want to make sure it's bulletproof and has all the learnings from v1), we can do the perfect thing from the start and we don't have to worry about backwards compatiblity

timint commented 1 year ago

Yeah your idea about data-lang="auto" makes sense. I can't think of a case why someone sets their html lang to spanish then outputs english content in it. But there are people for everything, so that's not to take for granted. Agree with you on the v2 thingy.

Rick-Hard89 commented 1 year ago

Any possibility of adding more locale alternatives to "html lang="?

For example I'm using Finnish, Swedish and English on my site. The default languages locale is "FI" for Finnish and "html lang="fi"" but for Swedish the plugin uses locale "sv_SE"and "html lang="sv-SE"" and for English it uses "html lang="en-US"" .

The locales or "html lang" cannot be changed in the multi-language plugin so maybe adding more alternative attributes to "html=lang" on your side would be possible?

merlinfuchs commented 1 year ago

@Rick-Hard89 I sadly don't fully understand what you are asking. You can set the language of the widget using the data-lang attribute as described here.

timint commented 1 year ago

@Rick-Hard89 I understood absolutely nothing of that. Are you sure you are not overcomplicating things? The proposed support for the lang attribute would resolve the language to be used to the closest parent node having the lang attribute set. This is the intended behavior of the lang attribute.

I just wanna point out "FI" is not a language code. Languages are lowercase "fi" and can be followed by a dialect in uppercase country code "fi-FI". As finnish is only spoken in Finland "fi" is good enough.

Rick-Hard89 commented 1 year ago

@merlinfuchs @timint I'm sorry maybe i should have explained better. I'm making my site with Elementor and using Contact form 7. FriendlyCaptcha have a plugin that can add the captcha checkbox to the forms before you can click send.

But i can only get the language for the default language "fi" to display on all three different languages when i set the language settings to "automatic". I thought the discussion earlier was about the FriendlyCaptcha plugin automatically sensing the "html lang=" and switching the language when i switch to the Swedish or English version of the site. I recently tried reCaptcha v2 checkbox and it worked well with switching the languages.

@merlinfuchs I'm not sure how to add the code to the Contact form 7 plugin to make it work so that you have to pass the captcha before clicking send.

timint commented 1 year ago

@Rick-Hard89 Show your code. The data-lang attribute doesn't have an "auto" yet. This is being discussed in this thread here in regards to supporting the standard lang attribute.

<!-- As of today FriendlyCaptcha does NOT honour the standard lang attribute -->
<html lang="fi">

  <!-- You will have to specify languange in the data-lang attribute -->
  <div class="frc-captcha" data-sitekey="<my sitekey>" data-lang="fi"></div>

https://docs.friendlycaptcha.com/#/widget_api?id=data-lang-attribute

Supported language codes are: en, fr, de, it, nl, pt, es, ca, da, ja, ru, sv, el, uk, bg, cs, sk, no, fi, lv, lt, pl, et, hr, sr, sl, hu, ro, zh, zh_TW, and vi.

Rick-Hard89 commented 1 year ago

@timint I understand. I managed to get it to work by changing the language of WP to Swedish and then creating a new form with CF7. The CF7 code then changed to:

<div class="wpcf7 no-js" id="wpcf7-f3160-p355-o1" **lang="sv-SE"** dir="ltr">

and the FRC code changed to:

<div class="frc-captcha dark" data-sitekey="<my sitekey>" **data-lang="sv"** data-attached="1">

Then i changed the language of WP to English and created another form.

Thank you for the help!

merlinfuchs commented 1 year ago

@Rick-Hard89 is talking about the setting for Wordpress plugin which already has an "auto" option. If you think that option doesn't work correctly (which might very well be the case) please open an issue at https://github.com/FriendlyCaptcha/friendly-captcha-wordpress

The discussion in this issue was about adding an auto option to the JavaScript library. Sorry for the confusion!

Rick-Hard89 commented 1 year ago

@merlinfuchs yes exactly it doesn't seem to work. At least not with my multi-language plugin. Sorry i posted in the wrong thread.