Some users have been using google chrome builtin translation system with
ERP5 back office (xhtml style), but the way google translation changes
the DOM sometimes break ERP5 interface.
This also have data privacy issue as this translation is done on google
servers.

https://www.w3.org/International/questions/qa-translate-flag recommends
using translate=no but the approach of the meta tag might be preferable
for our case as it prevents sending the page content to translation
service.

do nothing, but at least makes gadget compatible

See discussion on
nexedi/erp5@a7ffbc92 (comment 81088)

Backport nexedi/erp5!854 ( before merge )

/reviewed-on https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/39

This is needed to support datawarehouse on another database.

Tables, columns and index names needs to be escaped for syntax to be
valid.

Backport final state of nexedi/erp5!838 API changed a bit after first backport in https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/37

/reviewed-on https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/38

This fallback seems useless in this context, getClientAddr should be
available.

This test does not need to create an actual user as it just check
plugin extract login & password from request.
This test does not need to install the plugin in PAS, the actual check
instanciate another ERP5DumbHTTPExtractionPlugin.

This keep the current behavior. Invalidating all logins is also a way to
disable login for this user without having to find all tokens and
invalidate them one by one

for compatibility with login/password

Because this was broken, we took the liberty to introduce a breaking
change to fix naming, now type based scripts are *_getUserValue and must
return a user document, with a getUserId method returning the user id.

Make this plugin also an IAuthenticationPlugin which does all the job of
returning the user id.
It does not really make sense to delegate this to default authenticator.
A side effect is that token can still authenticate users with no
assignments, since tokens are scriptable, if this is a requirement, it
can be implemented in scripts.

also update test:

 - plugin must be enabled for IAuthenticationPlugin
 - check complete authentication sequence, not just extraction
 - update scripts to new names
 - simplify transaction management
 - don't set self.person, it was not used anywhere
 - update _createPerson to reindex, as said in docstring
 - merge all tests in on test component

This revert https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/37
which was a backport of an intermediate state of
nexedi/erp5!838

Revert this first backport to easily backport again the latest merged
version of nexedi/erp5!838

Backport nexedi/erp5!838

/reviewed-on https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/37

self.person is not used anywhere

for compatibility with login/password

no need to use different test components

also update _createPerson to reindex, as said in the docstring

 - plugin must be enabled for IAuthenticationPlugin
 - check complete authentication sequence, not just extraction
 - update scripts to new names

As script return user_ids it's more logical to name them *_getUserId

Make this plugin also an IAuthenticationPlugin which does all the job of
returning the user id.
It does not really make sense to delegate this to default authenticator.
A side effect is that token can still authenticate users with no
assignments, since tokens are scriptable, if this is a requirement, it
can be implemented in scripts.

Because this was broken, we took the liberty to introduce a breaking
change to fix naming, now type based scripts are getUserId.

backport nexedi/erp5!831 this is needed or https://lab.nexedi.com/nexedi/capago/merge_requests/370

/reviewed-on https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/36

The fields are displayed only if some portal types are configured as
member of payment_request group. This means that currently it's not
displayed by default.

backport nexedi/erp5!740

tests for booking in french language from https://lab.nexedi.com/nexedi/capago/merge_requests/363  needs it, probably on production it should not change anything as with "real zopes" we set the encoding in zope.conf.

66b4b55f did not apply, I just skipped this commit.

/reviewed-on https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/35

zope.conf default encoding is also used for responses and converters, so
for consistency we should also force default encoding there.
This is especially useful when running tests, because zope.conf is not
used and default values are used.

https://tools.ietf.org/html/rfc4329#section-7 states that text/javascript is obsolete.

Doesn't really matter in the end because WebPage_viewAsWeb forces the content type.

In HTTP/1.1 , when not specified , charset detault to ISO-8859-1

https://tools.ietf.org/html/rfc2616#section-3.7.1

> media subtypes of the "text"  type are defined to have a default charset value of "ISO-8859-1" when   received via HTTP

Zope adds a charset with default encoding (
https://github.com/zopefoundation/Zope/blob/2.13/src/ZPublisher/HTTPResponse.py#L512-L515 ) but does this only for text/ type, but we serve our javascript as application/javascript

backport nexedi/erp5!825/ for test
failure at
https://lab.nexedi.com/nexedi/capago/merge_requests/360/diffs#note_73137

/reviewed-on https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/34

According to pep-0263, python scripts can define encoding magic on
first or second line.
If we use for example such a script:

```python
  # coding: utf-8
  return "héhé"
```

then using .read() was wrong, because it return the script with headers,
ie:

```python
  ## Script (Python) "test_coding"
  ##bind container=container
  ##bind context=context
  ##bind namespace=
  ##bind script=script
  ##bind subpath=traverse_subpath
  ##parameters=
  ##title=
  ##
  # coding: utf-8
  return "héhé"
```

so the coding magic is no longer in first line and pylint complains
with error like:

Cannot decode using encoding "ascii", unexpected byte at position 11 (invalid-encoded-data)]

backport nexedi/erp5!796

mentioned in [Re: Create Bt5 with list of all accounting accounts
?](https://www.erp5.com/project_section/capago-project/forum/Create-Bt5-with-list-of-all-accounting-accounts-HLBp84CyNR/view?list_start=9&reset=1#2019138697)

/reviewed-on https://lab.nexedi.com/nexedi/erp5-capago/merge_requests/33