A source string “\N” in my .pot file prevents me from push this resource’s source strings to Transifex. If I remove that string from the file, push works. If I keep it, I get the following message (omitted organization, project, resource names):
[project].[resource] - upload of resource 'o:[organization]:p:[project]:r:[resource]' failed - parse_error: null value in column "string" of relation "resources_translation" violates not-null constraint
DETAIL: Failing row contains (1318096651, null, 44d0dc437936b13f7cea2f77053806bd, 5, 2023-05-24 04:00:46.230375+00, 2023-05-24 04:00:46.230375+00, 459636360, 20, 7302, 1, 3533169, API, f, null, c93b2b42-12db-416e-a8ce-463068f610ab, 232830, null, null, null, 44d0dc437936b13f7cea2f77053806bd, null, null, null).
CONTEXT: COPY resources_translation, line 1: "2023-05-24 04:00:46.230375 \N c93b2b42-12db-416e-a8ce-463068f610ab 20 2023-05-24 04:00:46.230375 \N ..."
That pot’s source string is really simple msgid "\\N", and the message’s last line mentions \N. I don’t know what that means, but seems related.
1 Like
Hello @rffontenelle ,
Thank you for reaching out to Transifex support.
Regarding your question, The \N is a line break that needs to be in lowercase so our parser can recognize it, I just did a test, and it worked :
Having \n :
Having \N :
Give it a try, and let me know how it goes.
Best Regards
Hi @Cesar_Garcia
I shouldn’t change the source string as the documentation expects it to be displayed as it is. Is there any flag or any other way I can tell Transifex this should not be parsed as a line-break character?
For now, I suppose I can hack a script to delete that source string from the POT file, causing the string to not be pushed to Transifex, but I would prefer to avoid this type of workaround.
1 Like
Hello @rffontenelle
Unfortunately, We have nothing to bypass this error except by changing the source code; our parser reads the file line by line and ensures the syntax is correct according to the file type. (This is standard)
Going over the file Im pretty confident this is a typo. Could you confirm with your team ?
Best Regards
I confirmed it is not a typo. It is a documentation showing regular expressions that can be used by that library.
For the record, I worked around this issue by patching any POT file to remove strings which has \\N as source string. Then I push the source strings to Transifex. Ugly, but it works:
msggrep -Ke '^\\N$' $pot > $tmp
msgcomm --no-wrap --less-than=2 $pot $tmp > $tmp2
mv $tmp2 $pot
Hello @rffontenelle
Thanks for letting us know what you use as a workaround, I apologize for the inconvenience caused.
If there is anything else I could do to help please let me know
Best Regards
Hello @Cesar_Garcia, please note that the workaround used does solve the problem of pushing resources, but doesn’t solve the problem of translating those problematic strings. By removing them from the resources we won’t be able to translate them in the target document.
Passing this case to development team as a bug would be highly appreciated. More details on Python documentation project context can be found here: Ilegal character breaks pushing source strings to resources · Issue #15 · rffontenelle/docspush-transifex · GitHub.
Kind regards
Hello @m-aciek @rffontenelle,
Sure, I will forward this case to my dev team so they can evaluate it and follow up with a bug report.
I will inform you as soon as I get an update from them.
Best Regards
1 Like
We were lucky that this string doesn’t need translation. 
Oh, in fact the translations aren’t needed in a number of cases. Still there are two strings in which \N is used inline:
Looks like Transifex only breaks when the msgid is exactly "\\N". Other cases where \\N is used in the middle of the text doesn’t seem to be breaking, and string is extracted perfectly – which is a great relief as we are still able to translate everything that needs to be translated.
Ah, thank you @rffontenelle for explaining. I didn’t do a double check. cc @Cesar_Garcia sorry for the confusion.
1 Like
Don’t worry @m-aciek,
I have forwarded the case to my dev team, They will review and implement a solution if needed in future releases.
Thanks for keep us updated @rffontenelle
Cesar
1 Like
