GNOME Bugzilla – Bug 741873
spanish translations of Epiphany's help breaks the build
Last modified: 2015-02-10 00:29:41 UTC
the Epiphany build in GNOME Continuous has been broken for a whole day with this error message: Warning: Could not merge es translation for msgid: You can also use the <keyseq><key>Ctrl</key><key>T</key></keyseq> keyboard shortcut to open a new tab or the new tab button in the top-left of the window. Error: Could not merge translations: ID tabs-link already defined Makefile:579: recipe for target 'es/es.stamp' failed make[2]: *** [es/es.stamp] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory '/ostbuild/source/epiphany/_build/help' Makefile:466: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/ostbuild/source/epiphany/_build' Makefile:397: recipe for target 'all' failed make: *** [all] Error 2 which seems to be related to this commit: commit 22765d4b038336a83033788227ca61622708f0d3 Author: Ekaterina Gerasimova <kittykat3756@gmail.com> Date: Sat Dec 20 22:04:20 2014 +0000 help: fix duplicate ID which was added in 4f9a7ef I have pinned Epiphany in Continuous to commit: 0b6fc8136a0941f078bdfac31e8fe388126187bc and I'll be happy to unpin it once this bug has been fixed.
Sorry but I don't see where the problem is in the Spanish string... could you please tell me how to fix it?
We don't know how to fix it :(
No? diff --git a/help/es/es.po b/help/es/es.po index b978150..8fdfdb7 100644 --- a/help/es/es.po +++ b/help/es/es.po @@ -674,8 +674,8 @@ msgid "" "shortcut to open a new tab or the new tab button in the top-left of the " "window." msgstr "" -"También puede usar el atajo del teclado <keyseq><key>Ctrl</key><key>T</key></" -"keyseq> para abrir una pestaña nueva o el botón de pestaña nueva en la parte " +"También puede usar el atajo del teclado <keyseq><key>Ctrl</key><key>T</key>" +"</keyseq> para abrir una pestaña nueva o el botón de pestaña nueva en la parte " "superior izquierda de la ventana." #. (itstool) path: credit/years
(In reply to comment #0) > which seems to be related to this commit: > > commit 22765d4b038336a83033788227ca61622708f0d3 > Author: Ekaterina Gerasimova <kittykat3756@gmail.com> > Date: Sat Dec 20 22:04:20 2014 +0000 > > help: fix duplicate ID which was added in 4f9a7ef This isn't related and wouldn't have broken the build. I also looked over the translation at the same time and couldn't find anything wrong with it.
(In reply to comment #4) > (In reply to comment #0) > > which seems to be related to this commit: > > > > commit 22765d4b038336a83033788227ca61622708f0d3 > > Author: Ekaterina Gerasimova <kittykat3756@gmail.com> > > Date: Sat Dec 20 22:04:20 2014 +0000 > > > > help: fix duplicate ID which was added in 4f9a7ef > > This isn't related and wouldn't have broken the build. I also looked over the > translation at the same time and couldn't find anything wrong with it. your commit definitely did not break the build, but the Spanish translation related to the change you made did; it seems that itstool does not like that particular change. (In reply to comment #3) > No? > +"También puede usar el atajo del teclado <keyseq><key>Ctrl</key><key>T</key>" > +"</keyseq> para abrir una pestaña nueva o el botón de pestaña nueva en la > parte " > "superior izquierda de la ventana." I thought about doing that, but looking at other translations it does not seem to make much of a difference: the msgfmt strings will be concatenated.
(In reply to comment #1) > Sorry but I don't see where the problem is in the Spanish string... could you > please tell me how to fix it? I honestly have no idea either. :-) the error seems to be coming from the process that merges the translations into the manifest file.
I don't think this is a bug in the Spanish translation, or anything in epiphany. I think it's actually caused by this libxml2 commit: https://git.gnome.org/browse/libxml2/commit/?id=f54d6a929af2a570396f0595a0e29064c908c12e When we xmlReplaceNode the original element with the translated element, the xml:id of the translated element now gets added to the document, but this happens before the xml:id of the original element is removed.
(In reply to comment #7) > I don't think this is a bug in the Spanish translation, or anything in > epiphany. I think it's actually caused by this libxml2 commit: > > https://git.gnome.org/browse/libxml2/commit/?id=f54d6a929af2a570396f0595a0e29064c908c12e > > When we xmlReplaceNode the original element with the translated element, the > xml:id of the translated element now gets added to the document, but this > happens before the xml:id of the original element is removed. tagging libxml2 and untagging Epiphany results in a successful build, so I think you're right. we should re-assign this bug to the correct component. Shaun: do you think it should be itstool or libxml2?
Right, when a node is moved to another document, libxml2 now checks IDs for uniqueness. Generally, it's the right thing to do. But since this might break existing code, I'm thinking about partially reverting that change.
The trouble is, the way it's implemented, it checks uniqueness at the wrong time. Take this document: <root> <node xml:id="myid">foo</node> </root> Get a reference to the node element. Create a new element that looks like this: <node xml:id="myid">bar</node> Then call: xmlReplaceNode(oldnode, newnode); Logically, this isn't adding a conflicting id. But xmlReplaceNode calls xmlSetTreeDoc on newnode before oldnode is fully removed from the document. That gives us an error, because the to-be-removed node with the same id isn't yet removed. If you're going to go down this path, then you probably need to recursively dig into oldnode calling xmlRemoveID before calling xmlSetTreeDoc on newnode. There's an added issue here of throwing validity (not well-formedness) errors on non-validating code paths. But even if I want validity checks, the above issue should be addressed.
Yes, the problem is that libxml2 calls xmlAddID as soon as a new node is created even if it isn't added to a document yet. It also doesn't call xmlRemoveID if a node is unlinked but only if it's destroyed. I think this is done for performance reasons. Otherwise, a whole subtree needs to be checked for every "add" or "unlink" call. My patch tries to fix the case where a node's ID wouldn't be removed from a document together with its node. This would lead to an error if a new node with the same ID was inserted subsequently. Also, all of this only surfaced with the 2.9.2 release where the ID uniqueness check was made more thorough. I got hit by this in a couple of places but usually it only results in a warning. I think the best solution for now is to revert the "xmlAddID" part of my commit.
This should now be fixed in libxml2 with the following commit: https://git.gnome.org/browse/libxml2/commit/?id=220a7baeeee484bbd356a506f23deb57c57e0056
should probably close this.