Weblate: When saving a translation I get Translation text too long! as error.

Created on 12 Nov 2018 · 14Comments · Source: WeblateOrg/weblate

Describe the bug
When saving a translation I get Translation text too long! as error.

To Reproduce
Steps to reproduce the behavior:
Try to translate a string. In our case 256 chrs.

Expected behavior
The string to be saved as usual

Screenshots
screenshot from 2018-11-12 15-12-46

The issue seems to be triggered by https://github.com/WeblateOrg/weblate/blob/9e02f3c4f8ee9f70f6681e5a16e29735038d1b6d/weblate/trans/forms.py#L526

For some reason the filed is detected as max 160 chr, the textarea, in the html has

<textarea name="target_0" maxlength="160" id="id_d635adb6e6754d11_0" dir="ltr" lang="en" tabindex="100" cols="40" rows="3" class="translation-editor form-control" style="overflow: hidden; overflow-wrap: break-word; resize: horizontal; height: 54px;">...</textarea>

If looks that get_max_length return 160 in
https://github.com/WeblateOrg/weblate/blob/9e02f3c4f8ee9f70f6681e5a16e29735038d1b6d/weblate/trans/models/unit.py#L1037

In my "Quality checks flags" I have:

ignore-end-question,ignore-end-exclamation,ignore-end-stop

Versions:

Weblate 3.2.2
Python 3.5.3
Django 2.1.2
Celery 4.2.1
celery-batches 0.2
six 1.10.0
social-auth-core 1.7.0
social-auth-app-django 2.1.0
django-appconf 1.0.2
translate-toolkit 2.3.1
Whoosh 2.7.4
defusedxml 0.5.0
Git 2.11.0
Pillow 4.0.0
python-dateutil 2.5.3
lxml 3.7.1
django-crispy-forms 1.7.2
django_compressor 2.2
djangorestframework 3.9.0
user-agents 1.1.0
jellyfish 0.6.1
pytz 2018.7
pyuca 1.2
PyYAML 3.12
tesserocr 2.3.1
Mercurial 4.0
git-svn 2.11.0

question

Source

goetas

All 14 comments

The problem is that maximal length is based on source string. And your source string doesn't contain actual source. You probably should use monolingual setup for your translations - the translation only contains keys and not source strings.

See https://docs.weblate.org/en/latest/formats.html#bimono and https://docs.weblate.org/en/latest/admin/admin.html#monolingual for more information.

nijel on 12 Nov 2018

I'm using XLIFF

      <trans-unit id="1025c70adf9143df4476efdfc08aedc259f2ad3c" resname="picture_approved">
        <source>picture_approved</source>
        <target>text.......</target>
      </trans-unit>

Should be this considered mono or bi-lingual?

goetas on 12 Nov 2018

As the source does not contain actual source string, it should be considered monolingual.

nijel on 12 Nov 2018

👍1

I ve tried to set it up as "monolingual" translations, and now saving works.

With with this new approach:

I had to configure the project primary language as "english" (this is a bit tricky, using "placeholders" the project language IMO makes no sense, but almost all the translation systems use a similar approach, so it can be on anyway)
I do not have anymore the original placeholder name but something called Context with file.ext///1025c70adf9143df4476efdfc08aedc259f2ad3c as value (apparently extracted from the xliff file from the id attribute in the translation unit. not really useful as that ID is automatically generated by the source-extractor we use).
The english file looks always 100% translated, ignoring the translation state attribute provided by XLIFF. This is the mos problematic issue as initially the english file does not contain real strings but only placeholders. Now it is not possible to find easily which strings need translation when new strings are added. Translators will have to go trough the whole file each time. (in the previous bi-lingual setup, I have workaround-ed this issue putting as project language a language not in use, so english translation percentage was correct)

goetas on 13 Nov 2018

Can you please post xliff snippet so that I can take a look?

nijel on 13 Nov 2018

<xliff xmlns="urn:oasis:names:tc:xliff:document:1.2" xmlns:jms="urn:jms:translation" version="1.2">
  <file date="2018-11-12T11:12:04Z" source-language="ar" target-language="en" datatype="plaintext" original="not.available">
    <body>
      <trans-unit id="5927c7df97028184fab2e56ab380d23bae0ba683" resname="greetings">
        <source>greetings</source>
        <target state="new">greetings</target>
      </trans-unit>
    </body>
  </file>
</xliff>

I have tried different configurations of source-language , but it seemed ignored

goetas on 13 Nov 2018

I have updated the XML

goetas on 13 Nov 2018

Weblate currently doesn't support XLIFF states, that's why you see those as translated. I've drafted patch in https://github.com/WeblateOrg/weblate/pull/2384, but it needs some review and testing before it can be merged.

The source is indeed ignored in the monolingual case as it's read from the base file. The "context" field stores unique identifier what is id in case of XLIFF files. Using resname instead was discussed in https://github.com/WeblateOrg/weblate/issues/2218, but somehow the discussion has died before reaching a conclusion.

nijel on 13 Nov 2018

goetas on 13 Nov 2018

The patch mentioned in https://github.com/WeblateOrg/weblate/issues/2218#issuecomment-419010869 should be close to final solution, it just needs proper testing and maybe some addition. Maybe after cleanup done in https://github.com/WeblateOrg/weblate/pull/2379 no further changes will be needed, but still that needs to be tested.

nijel on 13 Nov 2018

It turns out that no further changes are needed, so resname will be used as context since 6190db4ce64568b7ae03486bb46bdd82095c20b1.

nijel on 14 Nov 2018

👍1

Great news!

goetas on 14 Nov 2018

I think this can be closed.

Will keep an eye on https://github.com/WeblateOrg/weblate/pull/2384

goetas on 14 Nov 2018

Weblate is great so far!

goetas on 14 Nov 2018

👍1