After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 738340 - search specifiers don't work
search specifiers don't work
Status: RESOLVED FIXED
Product: geary
Classification: Other
Component: internationalization
master
Other Linux
: Normal normal
: 0.10.0
Assigned To: Geary Maintainers
Geary Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-10-11 08:06 UTC by Federico Bruni
Modified: 2015-03-20 20:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
from search specifier doesn't work (78.39 KB, image/png)
2014-10-14 21:21 UTC, Federico Bruni
Details

Description Federico Bruni 2014-10-11 08:06:23 UTC
I'm trying for the first time the search specifier (added in aac2956182a51f41c5787a715dbf5a8d393bc0c9) and don't work. It's always a full-text search.

Are you aware of it? (I can't find any open bug)
Comment 1 Jim Nelson 2014-10-14 17:23:59 UTC
Which search specifier are you using?
Comment 2 Federico Bruni 2014-10-14 21:21:17 UTC
Created attachment 288553 [details]
from search specifier doesn't work
Comment 3 Federico Bruni 2014-10-14 21:22:31 UTC
As you can see in the attachment, from:jim is actually searching in the body of messages.
This happens with any search specifier I've tried.
Comment 4 Jim Nelson 2014-10-21 22:09:56 UTC
What you're seeing is a duplicate of bug #714856: the search engine is returning only mail w/ "jim" in the From line, but the highlighter is showing all instances of "jim" in the mail.  It's confusing, but the search is working.

*** This bug has been marked as a duplicate of bug 714856 ***
Comment 5 Federico Bruni 2014-10-22 08:59:48 UTC
I disagree: as you can see in the image I attached the emails are coming from 'geary <bugzilla@gnome.org>'. Jim is only in the body of the emails.

I'm very sure that  this is a new bug.
Comment 6 Jim Nelson 2014-10-22 18:23:58 UTC
Sorry, I should have looked closer.

Something just occurred to me, though.  Have you tried "da:jim"?  The search specifiers are marked for translation.
Comment 7 Federico Bruni 2014-10-23 06:20:29 UTC
You are right! If I use italian it works.  I'm so used to Gmail that I didn't think about this possibility.  But actually I like it and I think that it's more user-friendly.

So the issue here is that it's not documented correctly in the translated help pages (at least in italian, didn't check the other languages). You should add a note to the help pot file so that translators are advised to translate the specifiers.

Let me know when you add it and I'll update the italian translation right away.
Thanks
Comment 8 Jim Nelson 2014-10-23 21:45:44 UTC
Pushed to master, commit 708b7c
Comment 9 Federico Bruni 2014-10-25 10:16:09 UTC
How can you trigger Gnome Damned Lies to update the po file? It's still marked as 100% translated:
https://l10n.gnome.org/vertimus/geary/master/help/it

BTW, the commit is different:

$ git log --grep 738340
commit dee8c2437bb7a3962065867c7865909f184bf19a
Author: Jim Nelson
Date:   Thu Oct 23 14:44:03 2014 -0700

    Note for translators regarding search operators and docs: Bug #738340
    
    Search operators are marked for translation, so the help documentation
    list must match the strings in the source file.
Comment 10 Jim Nelson 2014-10-28 18:38:47 UTC
I merely added comments to the strings in the source code.  The comments tell translators to be sure to translate the help documentation to match their search specifier strings.  There was no change to the documentation itself.
Comment 11 Federico Bruni 2014-10-28 20:05:54 UTC
Ok, but translators will never check again those strings (and fix possible errors) if the strings are not marked as fuzzy.

I _think_ I can update the file on Gnome Damned Lies even if it appears to be 100% translated. But I'm concerned about the other languages and translators who are not aware of this (for example, cs.po has the same mistake as it.po).
Comment 12 Federico Bruni 2015-02-25 15:07:47 UTC
I'm updating the it.po files provided by Damned Lies. I'm fixing this just because I'm aware of it but I cannot see any comment for translator in the relevant strings.
Comment 13 Federico Bruni 2015-02-25 15:37:09 UTC
ok, it's in the source po, I was checking the help po file
Comment 14 Jim Nelson 2015-02-25 20:35:16 UTC
Can you provide a patch marking those strings as fuzzy?
Comment 15 Federico Bruni 2015-02-26 11:59:25 UTC
I can do it. Let me know if there's any obvious mistake in this procedure:

Many PO files in git are out-of-date, so they do not contain the comment.
I should donwload the POT file from https://l10n.gnome.org/POT/geary.master/geary.master.pot

Then use Poedit to:

1. update each po file in my git branch from the POT file above.
2. mark as fuzzy the strings with ID from 277 to 284.
Comment 16 Jim Nelson 2015-02-26 20:02:35 UTC
We don't want to do it that way.  That .pot file is generated each time a commit is made to the git repo.  I believe any changes you make to it will be overwritten the next time a code commit is pushed.

Can the strings be marked as fuzzy in the code, via a comment?  That would be the way to do it.
Comment 17 Federico Bruni 2015-02-27 16:07:12 UTC
Apparently, adding a comment doesn't make the string fuzzy, because comments are also meant for developers and not for translators.

I've asked on the list of an italian team of translators. A person suggested to use gettext contexts (msgctxt) instead of comments; contexts _should_ trigger the fuzzy-matching of gettext.
Comment 18 Jim Nelson 2015-03-12 21:17:13 UTC
Federico, I unfortunately don't know enough about gettext and mallard to get this right and am time-constrained.  I know how to add context to strings in code, but I don't know how to add context to strings in Mallard (i.e. help) documentation.  I presume we need to mark both strings with the same context for the translators to understand.

Am I right about this?  Can you find out how to add context to strings in Mallard documentation?
Comment 19 Federico Bruni 2015-03-16 13:05:01 UTC
I found two options:
http://projectmallard.org/1.0/its

"Mallard allows attributes from external namespaces to be used on all elements. Consequently, the its:locNote and its:locNoteRule attributes may be used to provide localization notes.

If more extensive localization notes are needed, the comment element may be used. Using a its:rules element in an info element, one can clearly specify which editorial comments are localization notes."


its:locNote attribute seems the best option, but I should check if xml2po supports it. itstool supports it for sure:
http://itstool.org/documentation/its-and-po/

I'll let you know later
Comment 20 Federico Bruni 2015-03-16 16:34:45 UTC
I've followed the example under Comments here:
https://wiki.gnome.org/DocumentationProject/Guide/Translations

It works fine if I create the pot file with itstool.

This string:

<td><p its:locNote="The translated string must match the string in Geary source">
<input>attachment:<var>filename</var></input></p></td>

is turned into:

#. (itstool) path: td/p
#. The translated string must match the string in Geary source
#: search.page:28
msgid "<input>attachment:<var>filename</var></input>"
msgstr ""

which is also displayed correctly in Gtranslator (i.e. I can read the comment).

It doesn't work if I use xml2po. I'm using this command to generate the pot file:
xml2po -m mallard -o template.xml2po.pot help/C/*.page

which is basically the command I see in help/CMakeLists.txt

I guess that I'll have to contact the gnome doc guys on IRC.
If anyone knows more about gnome doc please speak up.
Comment 21 Shaun McCance 2015-03-16 18:33:43 UTC
If you want to use msgctxt to mark things fuzzy, itstool has an extension for that. <p xmlns:itst="http://itstool.org/extensions/" itst:context="some_context">

You'll probably be stuck with that context forever, so decide for yourself if it's worth it. Maybe somebody should just manually fuzzy the string in all the PO files in git.

xml2po doesn't support any ITS. itstool began as xml2po ported to understanding ITS. Why do you still care about xml2po? It should be completely replaced by itstool.
Comment 22 Federico Bruni 2015-03-16 19:50:23 UTC
I care about xml2po because this is what Geary is using in its scripts.
Also, it seems that xml2po is the default tool used by Gnome:
https://developer.gnome.org/gnome-doc-make/unstable/intro.html.en

Do you recommend itstool? I think that Damned Lies supports it, right?
Comment 23 Jim Nelson 2015-03-20 03:26:17 UTC
We're going to have to stick with xml2po for now, as I don't think we'll be migrating to itstool soon (not without a patch from an external contributor).
Comment 24 Shaun McCance 2015-03-20 18:59:49 UTC
OK, wow, we need to nuke that document entirely. xml2po hasn't been the default XML translation tool for GNOME since 2011. gnome-doc-utils has been deprecated for just as long. The current docs build scripts are in yelp.m4, part of yelp-tools, and that uses itstool. It seems, unfortunately, that Geary was set up from the beginning to use tools that had already been long deprecated.

I blame our inability to properly deprecate information on developer.gnome.org.
Comment 25 Jim Nelson 2015-03-20 20:48:35 UTC
(In reply to Shaun McCance from comment #24)
> xml2po hasn't been the default XML translation tool for GNOME since 2011.
...
> It seems, unfortunately, that Geary was set up from the beginning to
> use tools that had already been long deprecated.

To be fair, the Geary project was started in 2011 using waf, and later we migrated to CMake.  We probably just borrowed scripting from other projects at the time.

There's two issues:

* We need to mark the text in our current help files as fuzzy.  Is this something we can easily do today?

* We need to migrate to itstool, which I've ticketed at bug #746548.