closes odoo/odoo#67949

X-original-commit: 42d409f180381316c97abd0c0ef5a062656e6122
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

Mainly transifex issues but also some errors found through 'grep' checks.

Fix typos and obscure english strings in xml contents, fields strings/helps, some docstrings, ...
ensuring correct translations base (and fallback when translations isn't available).

closes odoo/odoo#57206

Related: odoo/enterprise#13032
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

The following rounding is incorrect:
```
>>> float_round(6.6 * 0.175, precision_digits=2)
1.15
```

Indeed, 6.6 * 0.175 = 1.155 ≈ 1.16.

In this specific case, the `epsilon` computed is not sufficient. A
precision of 53 gives:
normalized_value = 115.49999999999997
epsilon = 1.2823075934420547e-14
=> new normalized_value = 115.49999999999999

Bad luck, this is just not enough to tip the value in the right
direction.

However, a precision of 52 is sufficient:
normalized_value = 115.49999999999997
epsilon = 2.5646151868841094e-14
=> new normalized_value = 115.5

The value of 53 was chosen from the `binary64` number format precision.
In case of Python, the corresponding machine epsilon is 2^-52 [1].
Therefore, using 52 instead of 53 does make sense.

It is worth noting that the value of the machine epsilon
2^-52 = 2.2204460492503131e-16, which is still 2 orders of magnitude
below our dynamic estimation.

[1] https://en.wikipedia.org/wiki/Machine_epsilon
[2] `numpy.finfo(float).eps = 2.2204460492503131e-16`

opw-2047368

closes odoo/odoo#35521

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Adding a new rule to verify that precision_rounding is positive.

Before this commit:
when a precision_round was 0 or smaller than 0 the float_utils
functions gave as results:
* float_is_zero(0.0, precision_rounding=0.0) -> False
* float_round(1.25, precision_rounding=0.0) -> 0.0
* float_compare(1.0, 1.0, precision_rounding=0.0) -> 1

These results where at least not correct at worst not logic.

Now, the function raises an error when the precision_rounding
is not positive

Odoo no longer supports python 2, thus some of these helpers can and
have been replaced by python 3 built-ins, therefore there is no need for
them to stay defined.

The removed helpers are:
    * izip, imap and ifilter
    * unichr, text_type
    * implements_to_string, implements_iterator
    * string_types, integer_types
    * to_native

The python 2 shims have also been removed, and only the python 3 helpers
have been kept, because they can still be usable (i.e. accepting
both bytes and str for functions that can only accept one of the two)

[REM] pyjsparser: remove PY3 shims

They're no longer necessary as Odoo doesn't officially support python 2
anymore.

closes odoo/odoo#28519

This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.

This includes:
    * calls to imap/izip/ifilter replaced by map/zip/filter
    * uses of text_type replaced by str
    * uses of unichr replaced by chr
    * calls to implements_to_string, implements_iterator removed
    * string_types and integer_types replaced by str, int respectively
    * calls to to_native replaced by calls to to_text

This is done in preparation to the removal of these deprecated helpers
in the following commit.

The result of the following:
```
float_round(2.5, precision_rounding=0.05, rounding_method='DOWN')
```
is 2.45. Instead, 2.5 is expected.

In case of the `DOWN` method, epsilon should be added, not subtracted.
In the meantime, we introduce a slight reorganization of the method to
make it clearer.

opw-805008

Closes #20391