Firstly, I understand the spam concern, but I believe that can be stopped.
If a traditional registration form was to be implemented, it would save a lot
of time for both the administrators and users, and allow efficient flow of data
into the database without manual use. Also, if the focus is on manually
creating accounts, it wastes potential time for other stuff that you, as
admins, could be doing, rather than registering users onto the database. In the
case of spamming, or botting, there can be an ‘I AM NOT A ROBOT’ authenticator,
which I am sure you have seen before online, where users need to pass the BOT
test to be able to submit the registration form. I also have asked people about
what type of registration form they would prefer if they were attempting to
register on a particular website. I had everyone telling me “seriously, why
would I want admins to manually register an account for me, that is a waste of
time, and self-registering saves so much time”. So what I am trying to say is
that, like myself, people have suggested that they would be more appealed to a
self-registration user account system, and that there is a high chance that
people would lose appeal to the software/program/system and leave it.
I hope you can understand my perspective, and perhaps see the sense in a
traditional registration system.
From: Andrea Pescetti<mailto:pesce...@apache.org>
Sent: 08 February 2018 07:47
Subject: Re: Alternative solution for Pootle registration troubles...
Ahmad Alawsie wrote:
> I have raised this suggestion on Github:
> https://github.com/translate/pootle/issues/6805 where you can see what I
> think could be done to smoothen the registration process for a Pootle account.
That one is not a Pootle issue, so you can close that issue. That is
just a matter of how we setup it. The current setup is that we prefer to
reduce spam, so new accounts are only created on request in all our
infrastructure (wiki, Pootle, everywhere). Still, even if we decided to
let user self-create an account, all these systems require e-mail
verification, so we would still have exactly the same problem.
Actually, creating accounts manually is the only way to have the
workaround available: we just force a temporary random password and send
it to the user.
To unsubscribe, e-mail: l10n-unsubscr...@openoffice.apache.org
For additional commands, e-mail: l10n-h...@openoffice.apache.org