@brianteeman @infograf768 if we change NoCaptcha back to ReCaptcha do we should change the language file namens or should we still use nocaptcha there?

You can't. You would have to rename the original plugin to plg_captcha_recaptchalegacy then the nocaptcha plugin could be renamed. It gets tricky when you deal with the actual extension names (recorded in the database) as those and the language file names must match.

We could change the filename of NoCAPTCHA as that has never been released (if needed) but not the existing one. (as @mbabker said) so if you want to rename the file what to? Beyond the scope of this PR

i know @mbabker but as we have not ship it with any official release we can rename the nocaptcha plugin. To avoid confusing about noCaptacha and reCaptacha

e.g. the plugin filename is nocaptcha but the language strings call it reCaptcha

An example could be new ReCaptcha so we have plg_captcha_newrecaptcha.ini
other example recaptcha2 so we have plg_captcha_recaptcha2.ini

Beyond the scope of this PR

Sorry @brianteeman sure out of scope of this PR.

If you rename the file, you should rename the extension completely. We shouldn't have a nocaptcha plugin using a recaptcha2 language file. Please keep that in mind if you do go forward with that idea.

e.g. the plugin filename is nocaptcha but the language strings call it
reCaptcha

finder / Smart Search :x

On 11 January 2015 at 00:28, zero-24 notifications@github.com wrote:

Beyond the scope of this PR

Sorry @brianteeman https://github.com/brianteeman sure out of scope of
this PR.

—
Reply to this email directly or view it on GitHub
#5664 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

If you rename the file, you should rename the extension completely. We shouldn't have a nocaptcha plugin using a recaptcha2 language file. Please keep that in mind if you do go forward with that idea.

i know this was only the first idea / example.

reCaptcha

hehe Yes

finder / Smart Search :x

Yes..

Would therefore be I guess:
PLG_CAPTCHA_NOCAPTCHA="CAPTCHA - New reCAPTCHA"
etc.
Which gives

@infograf768 I don't think it is a good idea to call the actual version (NoCaptcha) "New ...", because in 1 year it will be not really new anymore, and if in another 1 or 2 years again a new version is raised by Google, then "New ... " will be "Old ...".
With using "Old ... " or "... (legacy)" for the old one it is different, because this is true from the beginning and will be true forever.
Another idea is to put Google's versioning somewhere into the text, i.e. not use "New ... " and "Old ..." but "... (V2)" and ".... (V1)" or whatever Google uses.

@richard67 @inforgraf768 New and Old are bad terms to use. If we end up dropping the old one when google drops support for that API - we are then left with New (no longer new) or we have to rename it then.

We want people to use the new plugin - the old one might stop working. We are only keeping the old one for people like @infograf768 who want to keep using their now discontinued global keys

@brianteeman Yes, "new" and "old" are bad terms, but "new" is worse than "old", as I tried to explain above:

If we call the 2 things "New something" and "Something" in the UI texts, then it is misleading, because the new is not new anymore after a few months, and the old one still looks as if still up to date somehow.

But if we call the 2 things "Something" and "Old Something" or "Something (Legacy)", then things are clear, and true also after a few months.

So we should not use "New Something" in texts, but we can use "Old Something" or "Something (Legacy)".

Got me now?

And of course I understood the discussion before regarding why to keep the old one.

@richard67 Of course I have got you that is EXACTLY what this PR does.

Rename the plugins
CAPTCHA - reCAPTCHA (Legacy)
CAPTCHA - reCAPTCHA

You got distracted from testing the PR by a comment

@brianteeman So it's ready for testing? I thought because of the ongoing discussion above there are still things to be clarified or corrected.

No. Please test

On 11 January 2015 at 17:07, Richard Fath notifications@github.com wrote:

@brianteeman https://github.com/brianteeman So it's ready for testing?
I thought because of the ongoing discussion above there are still things to

be clarified or corrected.

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/5664
http://issues.joomla.org/tracker/joomla-cms/5664.

—
Reply to this email directly or view it on GitHub
#5664 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@test Success, see screenshots:

@brianteeman In opposite to your description, you have added the text to the description for CAPTCHA - reCAPTCHA (Legacy) to the end and not to the beginning, and it is not in bold. Maybe you should change the description for the other testers?

oops - thanks - will do and thanks for testing

On 11 January 2015 at 17:36, Richard Fath notifications@github.com wrote:

@test https://github.com/test Success, see screenshots:
[image: screen shot 2015-01-11 at 11 32 55]
https://camo.githubusercontent.com/de178c42be3265c5194fd105ee0484c19f3da513/687474703a2f2f6973737565732e6a6f6f6d6c612e6f72672f75706c6f6164732f312f32333664623439623566613966663239323061376663663933313966386336642e706e67
[image: screen shot 2015-01-11 at 11 33 03]
https://camo.githubusercontent.com/5603ef0e1e30555ed5760e6632b700855c7a2c02/687474703a2f2f6973737565732e6a6f6f6d6c612e6f72672f75706c6f6164732f312f30373735633936616365663232663934653464396531633235383433613135342e706e67
[image: screen shot 2015-01-11 at 11 33 08]
https://camo.githubusercontent.com/b8b770ba9b222a47721a7cddab110f55db5c8bc7/687474703a2f2f6973737565732e6a6f6f6d6c612e6f72672f75706c6f6164732f312f39366435643161323165323436306335343466393863643738323734393362342e706e67
[image: screen shot 2015-01-11 at 11 33 14]
https://camo.githubusercontent.com/d934059e2ad93932d0ae4ebade8023e0b5889d6f/687474703a2f2f6973737565732e6a6f6f6d6c612e6f72672f75706c6f6164732f312f64396664356335366132363636633534316532663164346362393432313138312e706e67 [image:
screen shot 2015-01-11 at 11 33 43]
https://camo.githubusercontent.com/5ce0e2caf10490c9fbd83b8dfcec0732c648981a/687474703a2f2f6973737565732e6a6f6f6d6c612e6f72672f75706c6f6164732f312f63623666636363396239313362633733383631346165396132626335333434322e706e67 [image:
screen shot 2015-01-11 at 11 33 47]
https://camo.githubusercontent.com/a134524435ed4e95e0b206823f1e3d7ec9bae8a4/687474703a2f2f6973737565732e6a6f6f6d6c612e6f72672f75706c6f6164732f312f62636239376137326165613533646366396264646630386339646265363331642e706e67

@brianteeman https://github.com/brianteeman In opposite to your
description, you have added the text to the description for CAPTCHA -
reCAPTCHA (Legacy) to the end and not to the beginning, and it is not in

bold. Maybe you should change the description for the other testers?

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/5664
http://issues.joomla.org/tracker/joomla-cms/5664.

—
Reply to this email directly or view it on GitHub
#5664 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

P.S.: Regarding name of the new plugin, as long as not released yet:
Can it be changed from "nocaptcha" to "recaptcha2", and the names of the language files for the new plugins changed accordingly? (= other PR of course.)
And then in future if Google agan changes everything use "recaptcha3" and so on?
This would solve all confusions and inconsistencies between namings and UI texts from my point of view.

the problem with that idea is the same as calling it nocaptcha. we are
giving it a name that no one else including google does. and iirc it would
be 4 not 2 as it is apiv4

On 11 January 2015 at 17:45, Richard Fath notifications@github.com wrote:

P.S.: Regarding name of the new plugin, as long as not released yet:
Can it be changed from "nocaptcha" to "recaptcha2", and the names of the
language files for the new plugins changed accordingly? (= other PR of
course.)
And then in future if Google agan changes everything use "recaptcha3" and
so on?
This would solve all confusions and inconsistencies between namings and UI

texts from my point of view.

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/5664
http://issues.joomla.org/tracker/joomla-cms/5664.

—
Reply to this email directly or view it on GitHub
#5664 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I am not in favour of changing the language strings for the old plugin, specially if the new plugin uses the same name as the old one had.
Reason is very simple: we would get the same name if the language pack is not updated, or only partly.
Any change imho should be done to the new plugin not yet released.

So everyone has to suffer and have the wrong name just because a
translation is not updated. Sorry but thats just a plain daft argument to
me. Translations should be up to date and should not be used as an excuse
to hold back the core.

On 11 January 2015 at 18:24, infograf768 notifications@github.com wrote:

I am not in favour of changing the language strings for the old plugin,
specially if the new plugin uses the same name as the old one had.
Reason is very simple: we would get the same name if the language pack is
not updated, or only partly.
Any change imho should be done to the new plugin not yet released.

—
Reply to this email directly or view it on GitHub
#5664 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

We have to be legacy and realistic.

Might as well stick with tables and html4 then. We have to improve this translation process if it is holding back new features and/or forcing stupid decisions

Seriously though how would a site using a non updated language file see the wrong information.
1. IIRC dont you see en-GB if there is no local translation
2. both plugins use different constants
So how can the confusion arise

Please show me a real world example

Please show me a real world example

SImple:
Pick en-US or en-AU.
A user updates a 3.3.6 joomla via joomlaupdate (or a user installs a brand new 3.4.0 and then installs the en-US or/and en-AU packs), and, for any reason these packs are not yet ready (which is often the case as it may take a few days for the TT to release them or the TT is absent at release time).

The constant for the 'legacy' plugin is still the same with the old value in en-US and en-AU.
PLG_CAPTCHA_RECAPTCHA="Captcha - ReCaptcha"

The new plugin has this value in en-GB (which indeed is displayed by default)
PLG_CAPTCHA_NOCAPTCHA="CAPTCHA - reCAPTCHA"

Without being too stupid, one has to admit that choosing between these 2 in the dropdown is slightly confusing...

But also, in any other language, let's say that the TT forgets to update the value for the 'legacy' plugin and creates/translates the new plugin ini files (this may happen as it is not as easy as some think to not forget some stuff, no one is as perfect as some surely are...). Same issue until someone finds it out and let it know to the volunteer TT in charge.

We have to improve this translation process if it is holding back new features and/or forcing stupid decisions

Legacy is legacy and language strings are considered as part of legacy.

I am sure you will find a non stupid way to get all translations correctly done and in time for all our languages in the near future.

Sorry but I really do not see or accept why joomla core has to suffer for 6
months because a single TT might not do what they are supposed to do.

. Rephrasing something for a more accurate description or proper en-GB
grammar is not.

On 12 January 2015 at 07:11, infograf768 notifications@github.com wrote:

Please show me a real world example

SImple:
Pick en-US or en-AU.
A user updates a 3.3.6 joomla via joomlaupdate (or a user installs a brand
new 3.4.0 and then installs the en-US or/and en-AU packs), and, for any
reason these packs are not yet ready (which is often the case as it may
take a few days for the TT to release them or the TT is absent at release
time).

The constant for the 'legacy' plugin is still the same with the old value
in en-US and en-AU.
PLG_CAPTCHA_RECAPTCHA="Captcha - ReCaptcha"

The new plugin has this value in en-GB (which indeed is displayed by
default)
PLG_CAPTCHA_NOCAPTCHA="CAPTCHA - reCAPTCHA"

Without being too stupid, one has to admit that choosing between these 2
in the dropdown is slightly confusing...

But also, in any other language, let's say that the TT forgets to update
the value for the 'legacy' plugin and creates/translates the new plugin ini
files (this may happen as it is not as easy as some think to not forget
some stuff, no one is as perfect as some surely are...). Same issue until
someone finds it out and let it know to the volunteer TT in charge.

We have to improve this translation process if it is holding back new
features and/or forcing stupid decisions

Legacy is legacy and language strings are considered as part of legacy.

I am sure you will find a non stupid way to get all translations correctly
done and in time for all our languages in the near future.

—
Reply to this email directly or view it on GitHub
#5664 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Wow... "suffer". I already feel the pain spreading all over the world behind the scenes, horrible golem with dark-red eyes, kidnapping young kids and doing terrible things with them in en-GB.
:)

BTW, about "suffer":
"Je suis Charlie"

That is so inappropriate that it is not true. Closing this and I will not
bother to contribute any more fixes to Joomla while you are able to
continually block any change. You have done it for 9 years - enough

On 12 January 2015 at 10:05, infograf768 notifications@github.com wrote:

Wow... "suffer". I already feel the pain spreading all over the world
behind the scenes, horrible golem with dark-red eyes, kidnapping young kids
and doing terrible things with them in en-GB.
:)

BTW, about "suffer":
"Je suis Charlie"

—
Reply to this email directly or view it on GitHub
#5664 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Why dont we just go back to using mambo

On 12 January 2015 at 10:10, Brian Teeman brian@teeman.net wrote:

That is so inappropriate that it is not true. Closing this and I will not
bother to contribute any more fixes to Joomla while you are able to
continually block any change. You have done it for 9 years - enough

On 12 January 2015 at 10:05, infograf768 notifications@github.com wrote:

Wow... "suffer". I already feel the pain spreading all over the world
behind the scenes, horrible golem with dark-red eyes, kidnapping young kids
and doing terrible things with them in en-GB.
:)

BTW, about "suffer":
"Je suis Charlie"

—
Reply to this email directly or view it on GitHub
#5664 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Hehe...

This is not an entirely problem-free solution, but there are enough hints for all but the most cognitively challenged users to figure out the obvious solution.

As an onlooker here, I can see where both of you are coming from, but for the sake of everyone's sanity, a line has to be drawn somewhere. Yes, not every translator may update the modified strings for 3.4.0 in a timely manner, or even at all, but does that truly mean that we should not change the strings at all? By this logic, it should be suggested that we move our code hosting (and download provider) to a solution that is not GitHub due to their recent blocking of the website since users in India are unable to access our resources.

The fact is we dug ourselves into this hole with how we managed the changed API by adding a completely new plugin with an inaccurate name, we now need to get ourselves out of that hole. As Google calls both services reCAPTCHA, our options are limited. One option is to leave it as is since Google is "calling it the No CAPTCHA reCAPTCHA experience". Another option is to rename the new plugin "No CAPTCHA reCAPTCHA". Yet another option is the proposal Brian suggested with this PR. Whatever the choice is going to require a conscious decision by everyone here, with an understanding of what it means for our default install options as well as the translations. Flat out dismissing any option because someone may not update is not a solution to me; in that case we can shut down this GitHub repository and stop enhancing Joomla since we know users do not update their installations.

"calling it the No CAPTCHA reCAPTCHA experience"

They are today but will they be tomorrow? Since they changed the API they
have already reduced the "visibility" of the term " No CAPTCHA" on their
web site. Next month they might remove it completely

On 12 January 2015 at 13:20, Michael Babker notifications@github.com
wrote:

As an onlooker here, I can see where both of you are coming from, but for
the sake of everyone's sanity, a line has to be drawn somewhere. Yes, not
every translator may update the modified strings for 3.4.0 in a timely
manner, or even at all, but does that truly mean that we should not change
the strings at all? By this logic, it should be suggested that we move our
code hosting (and download provider) to a solution that is not GitHub due
to their recent blocking of the website since users in India are unable to
access our resources.

The fact is we dug ourselves into this hole with how we managed the
changed API by adding a completely new plugin with an inaccurate name, we
now need to get ourselves out of that hole. As Google calls both services
reCAPTCHA, our options are limited. One option is to leave it as is since
Google is "calling it the No CAPTCHA reCAPTCHA experience". Another option
is to rename the new plugin "No CAPTCHA reCAPTCHA". Yet another option is
the proposal Brian suggested with this PR. Whatever the choice is going to
require a conscious decision by everyone here, with an understanding of
what it means for our default install options as well as the translations.
Flat out dismissing any option because someone may not update is not a
solution to me; in that case we can shut down this GitHub repository and
stop enhancing Joomla since we know users do not update their installations.

—
Reply to this email directly or view it on GitHub
#5664 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Your crystal ball works as well as mine

@infograf768 Maybe a post-install message could inform about the new plugin and the possible naming confusion if having old language files when this PR here is accepted? Would this be a way to mention your concerns?

@brianteeman As an en-GB native speaker, could you advice with a good text for such a post-install message, if this is accepted to be useful?

To both: Make love, not war ;-)

@richard67 sorry I am not interested in adding a post install message that says your translation of joomla is out of date. And if the language strings aren't translated then it is just as unlikely that this post install message is not translated so you are stuck again if you dont speak english

@brianteeman The post install message could explicitely point on the change of the naming for the (old) reCaptcha plugin and why there is a new one, and the text could even mention their extension IDs to be sure nothing is mixed up, and anyone who doesn't speak English will see there is at least something related to some reCaptcha plugins (I think the string "reCaptcha" is even regognized by Chinese or Russian site admins), and so in case of problems they can paste it into Google tranlator or whichever else they want to use.

There is value in the message for upgraded sites explaining the difference.
But if we assume that it is correct and the lang files are not updated and
people have to rely on online translators to explain the two plugins with
the same name and to use the id etc then I think it is creating a very
complicated message which I doubt online translators will do a good job
with. Its just creating a problem to solve a problem that should not even
exist.

@brianteeman Well, I just thought it could be better than nothing to solve the possible confusion which @infograf768 mentioned above. Am curious on his opinion.

I still think that, for legacy reasons, it is the new plugin's name which has to be changed in the string.
Another proposal:
PLG_CAPTCHA_NOCAPTCHA="CAPTCHA - reCAPTCHA (2015)"

The rest of the PR is OK for me.

It makes no sense to call it 2015. It was released in 2014. Why invent
names for other peoples services for a problem that probably doesnt exist
On 13 Jan 2015 07:18, "infograf768" notifications@github.com wrote:

I still think that, for legacy reasons, it is the new plugin's name which
has to be changed in the string.
Another proposal:
PLG_CAPTCHA_NOCAPTCHA="CAPTCHA - reCAPTCHA (2015)"

The rest of the PR is OK for me.

—
Reply to this email directly or view it on GitHub
#5664 (comment).

Closing in favour of #5888