[fix, CI] Push to Transifex from master, fix multiline strings for xgettext

[Frenzie]

Related to #5237

[Frenzie]

It looks like you need a workflow for this context stuff. The docs don't really say so: https://circleci.com/docs/2.0/contexts/#creating-and-using-a-context

But https://discuss.circleci.com/t/contexts-feedback/13908/12

So, annoying. :-)

[Frenzie]

Curious fact: three new strings seem to have shown up:

They look like they're actually typos:

koreader/frontend/util.lua

Line 924 in fbd331d

return false, T(_("Extracting archive failed:\n\n%1", archive))

koreader/frontend/apps/cloudstorage/ftp.lua

Line 155 in fbd331d

local info_text = T(_"Type: %1\nName: %2\nAddress: %3", "FTP", item.text, item.address)

koreader/frontend/apps/cloudstorage/webdav.lua

Line 148 in fbd331d

local info_text = T(_"Type: %1\nName: %2\nAddress: %3", "WebDAV", item.text, item.address)

koreader/frontend/apps/cloudstorage/dropbox.lua

Lines 128 to 129 in fbd331d

	info_text = T(_"Type: %1\nName: %2\nEmail: %3\nCounty: %4",
	"Dropbox",info.name.display_name, info.email, info.country)

Edit: no scratch that, of course _"string" is a valid function invocation. Only the util one is a typo.

[poire-z]

Uh, reverting 335a513 (#4524, where we agree it was preferable), which reverted 9971eb8 (#4132), so we're back there ?

[Frenzie]

Unfortunately so. xgettext apparently doesn't do koreader/koreader-misc@d72e711

Browsing through the xgettext test cases they don't actually properly test newlines.

Perhaps it's really easy to patch. x-lua.c says things like this (but that's for multiline comments). I'll check some more tomorrow.

                      /* Ignore leading spaces and tabs.  */
                      if (buflen == 0 && (c == ' ' || c == '\t'))
                        continue;

[Frenzie]

@poire-z I wrote this proof of concept patch for xgettext:

diff --git a/gettext-tools/src/x-lua.c b/gettext-tools/src/x-lua.c
index 3a2296f36..1eed3dccc 100644
--- a/gettext-tools/src/x-lua.c
+++ b/gettext-tools/src/x-lua.c
@@ -740,6 +740,18 @@ phase3_get (token_ty *tp)
 
           string_start ();
 
+          /* Ignore the first newline after '[[' because so does Lua. */
+          c = phase1_getc ();
+          if (c == '\\')
+            {
+              c = phase1_getc ();
+              if (c != 'n')
+                {
+                  string_add ('\\');
+                  string_add (c);
+                }
+            }
+
           for (;;)
             {
               c = phase1_getc ();

[poire-z]

Kudos for following that ugly coding style :)
Haven't looked at the surrounding context, but won't you be consuming the \ (and its next char), if it's not followed by a n ? So a \t will disappear?

[Frenzie]

You're right, there's something very wrong there. :-D

[poire-z]

But re-reading that snippet, you were indeed re-adding them if they were not \n. But may be not when the first one is not a \.
And re-adding them at the start or end or elsewhere?

[Frenzie]

I massively overthought the buffer. Apparently this suffices:

diff --git a/gettext-tools/src/x-lua.c b/gettext-tools/src/x-lua.c
index 3a2296f36..262f688cc 100644
--- a/gettext-tools/src/x-lua.c
+++ b/gettext-tools/src/x-lua.c
@@ -740,6 +740,13 @@ phase3_get (token_ty *tp)
 
           string_start ();
 
+          /* Ignore the first newline after '[[' because so does Lua. */
+          c = phase1_getc ();
+          if (c != '\n')
+            {
+              string_add (c);
+            }
+
           for (;;)
             {
               c = phase1_getc ();

_([[


only two newlines]])

_([[	


tab two newlines]])

_([[ 


space two newlines]])

_([[just one line]])

#: reader.lua:16
msgid ""
"\n"
"\n"
"only two newlines"
msgstr ""

#: reader.lua:21
msgid ""
"\t\n"
"\n"
"\n"
"tab two newlines"
msgstr ""

#: reader.lua:26
msgid ""
" \n"
"\n"
"\n"
"space two newlines"
msgstr ""


#: reader.lua:30
msgid "just one line"
msgstr ""

[Frenzie]

@poire-z

And re-adding them at the start or end or elsewhere?

Yes, I was missing something like an else condition in the above but I was too focused on my specific "should eat newline" scenario. :-)

[Frenzie]

Anyway, I'll look into reporting the bug and hopefully the maintainer can rewrite it properly in less than a minute if necessary.

From the README:

Report bugs

• in the bug tracker at https://savannah.gnu.org/projects/gettext
• or by email to bug-gettext@gnu.org.

[Frenzie]

@poire-z Alright, I noticed another function. :-P

diff --git a/gettext-tools/src/x-lua.c b/gettext-tools/src/x-lua.c
index 3a2296f36..e0dd99709 100644
--- a/gettext-tools/src/x-lua.c
+++ b/gettext-tools/src/x-lua.c
@@ -740,6 +740,13 @@ phase3_get (token_ty *tp)
 
           string_start ();
 
+          /* Ignore the first newline after '[[' because so does Lua. */
+          c = phase1_getc ();
+          if (c != '\n')
+            {
+              phase1_ungetc (c);
+            }
+
           for (;;)
             {
               c = phase1_getc ();

That way the character is actually processed properly by the rest of the code; of course it shouldn't be just blindly added.

[poire-z]

Isn't there a peekc() ?

[Frenzie]

This pattern seems to be more or less how the rest of the code does it, for example:

      else
        {
          /* Minus sign.  */
          phase1_ungetc (c);
          return '-';
        }

Edit: anyhow, submitted

https://savannah.gnu.org/bugs/index.php?56794