Contributor agreement field recognized as spam

[1u]

When editing the Contributor agreement of a component, I often get an error "This field has been identified as spam!"
I try to format our guide nicely and it's really annoying. Sometimes the error appears even if I didn't change anything.

[nijel]

Can you please share the problematic text? We rely on Akismet in this.

[1u]

This text underneath eventually got accepted. When I try to add a newline/paragraph before the list (in order to show it as a list) it doesn't allow it anymore and shows the spam alert. when I remove the newline again and try to save the same as it was accepted before, it doesn't accept it anymore...

removing the link at the end didn't seem to make a change.

Btw: Not crucial for us, was just annoying when I tried to put it and I thought I'll report it. And it seems to be the wrong place to state our syntax info anyways :)

thx and cheers!

#### Hi there

Thank you for helping with the translation of Openki!  🤗  
Here are some guidelines and some help. Please read them carefully before you start to translate.

### Style of speech 
We use a casual, every day language for the interface.  
Translate the meaning and formulate it in your own way. When it sounds strange just rephrase it. If a word gets lost and the content stays the same, even better. Openki addresses all users by their first name. It's totally okay to be informally as if the users were good friends.
Where possible we use a gender-neutral, inclusive language. We avoid gender-specific pronouns and try to use gender-neutral ones. As well we use gender-neutral titles and roles... without sounding too weird though.

### Some technical stuff about the syntax:
 Words in capital letters in brackets like `{NAME}` are variables. Don't translate the words inside them, transfer them as they are.   
Sometimes a translation requires several variations. Let's make an example: For a course there might be no participant, 1 participant or 2 participants.  
So we need a translation for each case
 - for zero `=0`, 
 - for one `=1` or `one`, 
 - for the rest  `other`. 
 - The applied syntax looks as follows:
 - `Create {COUNT, plural, one {event} other {# events}}` becomes:
 - `Erstelle {COUNT, plural, one {Veranstaltung} other {# Veranstaltungen}}`
 - `#` stands for a Number.
And don't forget any punctuation marks!

[Here you can find the complete format guide](https://messageformat.github.io/messageformat/guide/)

[nijel]

We definitely need a way to track such things and report false positives to Akismet.

[1u]

Update

Same happened now to the instructions field.

btw: In the docs it is described as url field but at the same time it says "You can use Markdown and mention users by @username." I think is nice, not to redirect users away from weblate just to show them some instructions.

[nijel]

It used to be just URL, but got changed to text field, but the docs was not updated. I've fixed that now.

[nijel]

• We should consider using X-akismet-pro-tip header value in the Akismet response.
• We should log the spam checks and add an admin interface to mark false positives/negatives.

[comradekingu]

@1u Feature! ;)

Could be that it is too long?
Only qualitative considerations to follow:

---

You would do much better to instead use the instruction field and the announcements, for actual info.

When you create the barrier to entry that is a CLA, it doesn't keep people that don't read it out,
but it becomes impossible for the people that care about what they license themselves to do to correct matters afterwards.

Informality doesn't exist in some languages. If the translator can't tell as much of the source language, who are you helping?

Replicating friendly speech between friends into the language of interfaces that aren't sentient is an extremely delicate task.
I'd leave this to the individual translator to do with as needed, instead of posing it as a required licensed agreement.
I was going to be more helpful, but https://openki.net/translate isn't up.

If you don't also do actors by gender in addition to enumeration, you are the one creating the problem of misrepresentation in languages where it applies. Being the perveyor (pun intended) of speech isn't neutral.
If it is not known, and no neutral term exists, that is generally the lesser of available mistakes,

"Inclusive language" is counterproductive for reasons why it doesn't do anything well in addition to what is just more elegant language. Omission of something that could be said to be "inclusive language" is always preferable.
As such, its true distinction is that of always just being poorer language "where possible".
Exactly there you have the crux of the problem summed up. Less precise, and a preference for the worse.

Since it excludes good language for the quality of being present, making its presence felt as an active choice is done on part of the reader, instead of in part. In no way are assumptions improved by force.
Choice is thus not represented in "inclusive language", despite the consistency of its naming being misleading.

Fortunately most cultures don't have this compelled speech, and there is nothing friendly or informal about mandating its use.
It looks wrong because it is wrong. Where you are otherwise deciding to create a problem of representation in just one of the sexes, therein lies the problem to be had. Of all possible combinations, that makes the worst of the not even worst premise.
Worse yet is ending up trying to replicate worse language, by re-inventing it in languages where it doesn't exist at all.

Every other project removed this type of license/suggestion, except one where it greatly reduced quality and volume.

Use the informal _DE language code for informal language, and create your own for whatever else if you believe choice is inclusive. Imposing non-language is exclusively wrong.

Use of punctuation (in particular the exclamation mark) isn't the same across languages.
What you do is not carry intent, into something that is shouting at the user.

If the technical placeholder description is doing anything, why is it not affixed to the relevant strings instead?

The ellipsis is "…", and not tripledot "..."

[github-actions]

Thank you for your report; the issue you have reported has just been fixed.

• In case you see a problem with the fix, please comment on this issue.
• In case you see a similar problem, please open a separate issue.
• If you are happy with the outcome, don’t hesitate to support Weblate by making a donation.