Closed (fixed)
Project:
Localization server
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
5 Sep 2024 at 08:09 UTC
Updated:
4 Jan 2025 at 13:02 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
gábor hojtsyMoving the localization server which is where the error shows up. Can you not save it or "just" an error shows up but you can still save it?
Comment #3
kartagisNo I can't save it and the page it's on at all.
Comment #4
kartagisAlso, please see this, it's treated as a variable.
Comment #5
fmb commented:API-specification-compliantpattern should be present in the translation.Comment #6
kartagisIt's coming from the jsonapi core module. I agree that the pattern should exist, but it seems we need a different aproach to parse it or distinguish the colon from a placeholder in this case.
Comment #7
guiu.rocafort.ferrerI was not able to replicate this issue in a local environment:
I used main branch from drupal-infrastructure gitlab repository,
I used 3.0.x-dev branch for l10n_server module.
The string id i tried to translate, and had no problem is the #2718592
Comment #8
fmb commentedComment #9
fmb commentedString 5052 (Audio File Info) does not have this issue. In string 2718592, the "JSON:API-specification-compliant" is partly interpreted as a replacement token (
:API-specification-compliant), apparently because of the colon. If you can replicate this bug, it might be related to the regexp in the TranslateForm::validateForm() method.Comment #10
guiu.rocafort.ferrerThe string id i wrote in the comment #7 was wrong, i did not realise the id in my local setup is different than the one in localize.drupal.org, so İ updated the comment accordingly.
Sorry about that.
Comment #11
kartagisOf course it has no issues Guiu, because it doesn't have a colon. I suspect all strings that have colon will have this issue.
Comment #12
kartagisIt is most interesting Guiu, you had no problem with the Spanish translation and yet I had problem with the Turkish translation.
Comment #14
guiu.rocafort.ferrerWe found out that the code was treating JSON:XXXXXX as a variable, this is a general problem where it is interpreting JSON:API as a variable name, when it is actually the drupal core submodule name.
I added an exception to the regular expression checking the variables, that would ignore any value starting with "JSON:" from being interpreted as a variable.
Comment #16
guiu.rocafort.ferrer@fmb I have checked that in the frontend the variables are not incorrectly hightlighted by the javascript code.
Comment #17
fmb commentedThanks Guiu! According to my tests, this does not disrupt the translation form.
This now needs to be backported to 7.x-1.x-dev.
Comment #19
kartagisWhen will this take effect? Because I'm still getting the exact same error, leaving me unable to save. Maybe that string has to be re-exported? Also, if you look at https://regex101.com/r/GLn0cs/1, that pattern doesn't match. Then again, I might be doing something wrong.
Comment #20
fmb commented@kartagis for now, the fix was applied to the 3.0.x branch of the l10n_server module, which is currently under development. The next step is to backport it to the older 7.x-1.x branch, which is still the live version (i.e. the one in use on localize.drupal.org).
It is a good thing that
JSON:APIdoes not match, it means it will not be mistaken as a replacement token.Comment #22
guiu.rocafort.ferrerI have applied the changes in a new merge request to 7.x-1.x (3472254-wrongly-parsed-sentence-7.x).
Comment #24
fmb commentedThanks Guiu! I successfully tested this on a development Drupal 7 instance. Failing tests are not related to this change. @drumm, could you deploy this onto the live instance (localize.drupal.org)?
Comment #26
kartagisI don't know if I should file a new ticket because I'm getting a similar error, so... This time the error is
Missing variable(s): @extensionand this is the string.Comment #27
fmb commentedWhat is the translation you are trying to save?
Comment #28
kartagisIt's 3037500.