Re: [Tracker] Updating .po files

[Martyn Russell <martyn imendio com>]

On 09/12/08 13:49, Luca Ferretti wrote:
> Il giorno mar, 09/12/2008 alle 12.28 +0000, Martyn Russell ha scritto:
> > On 09/12/08 11:32, Luca Ferretti wrote:
> > > There is no need to regenerate .po files. Translators should grab
> > > automatically updated po files from http://l10n.gnome.org/ or manually
> > > check out code and use `intltool-update` before translate it.
> > While this may be the case. They are actually not being updated.
>
> I don't understand. Why do you think .po files are not updated? Or,
> better, what do you mean for "updated"?

I mean updated in the sense that this page describes how you update a 
translation:

  http://live.gnome.org/TranslationProject/SvnHowTo#line-164

Which says you use intltool-update. You can do this for ALL po files by 
doing:

  make update-po

Then do an svn diff to see what has changed and it is a lot.

I would be the first to admit that my knowledge on translations and how 
it all works is a bit vague. But from that page and my understanding, 
our translations contain a lot of old strings which should be removed. 
Doing make update-po should do this as I understand it?

This is what I get if I do it now:

  http://pastebin.com/f1d040182

Now, fuzzy (as I understand it) usually means that the translation has 
changed in the code.

> Check for example the Estonian translation. On svn you have this[1], on
> l10n.gnome.org this[2].
>
> The reference stings on [2] (msgid) are updated to latest tracker code,
> see the  POT-Creation-Date value. Of course a lot of msgstr are not
> "updated" (no 100%) 'cause the last translation update was about 1 years
> ago.
> PO files on l10n.gnome.org are "updated" from reference messages to
> translate point of view.

I am not saying they are never updated. I am saying old translations 
that used to be in the code are not being removed.

> About .po files in svn, run `make` in po directory, then run `msgunfmt
> et.gmo`. GMO files only contains translated strings, as it should be.

> If you mean "translations are not 100%", this depends on translators
> works, not on wrong po files generated by gettext/intltool

No I am not saying that.

> > >           -l, --limit=LIMIT   Limit the results to LIMIT (default 512)
> > >
> > > while now it's something like
> > >
> > >           -l, --limit=512     Limit the results
> > >
> > > I'm working on it, I'll provide an initial patch this week.
> > That's exactly what the limit=512 means. It means, that's the default.
>
> To be honest I never see this kind of convention. All GNU programs (for
> exampel coreutil, tar) are using uppercase for options' arguments (i.e.
> stuff that user will decide on) but don't propose a value. Try for
> example `tar --help` and you'll see stuff like:
>
>          --checkpoint[=NUMBER]  display progress messages every NUMBERth
>                                 record (default 10)
>          --no-quote-chars=STRING   disable quoting for characters from
>          STRING
>          --quote-chars=STRING      additionally quote characters from
>          STRING
>
> And similar. Following GNU convention, limit=512 means that --limit can
> only use 512 as argument :)

> > This is something which is defined in the GOption configuration.
>
> Of course, I know, the GOptionEntry->arg_destription, the API ref says
> its a "placeholder to use for the extra argument parsed by the option in
> --help output ". But it should be a "description" (LIMIT, or NUMBER, or
> SERVICE), not a "value" (512, or 3, or EmailAttachments).

You are right of course. Recently actually I was caught out because I 
forgot that there even was a limit and thought Tracker was broken. I 
wanted to make the default value more prevalent because of this (by 
printing out some statement if num_hits == limit stating that there is 
probably more available.

If you are writing a patch, that could also be done.
I think adding --limit=NUMBER would be fine as long as we have a default 
in the comments.

> > If you notice, other non-default command line switches don't have
> > anything set there. There is no need to patch this.
>
> > From my point of view, there are other stuff that needs to updated too.
> So let me list here.
>
> First of all the --offset option, like --limit I think it should appear
> --offset=OFFSET, not --offset=0

I actually think adding "OFFSET" after --offset tells me absolutely 
nothing at all. Why not have NUMBER - that's more obvious. I mean it's 
like having TRUE=TRUE.

> Then I think --path and --service descriptions are wrong too. By now
> running `tracker-xxx --help` they appears like
>
>          -p, --path    Path to use in query
>          -s, --service Search from a specific service

OK. Some things require a path an some don't (like tracker-files).

> But you can't use them without an argument, so should be at least
> patched as follow:
>
>           static GOptionEntry   entries[] = {
>                  { "path", 'p', 0, G_OPTION_ARG_STRING,&path,
>                    N_("Path to use in query"),
>          -         NULL,
>          +         N_("PATH"),
>                  },
>                  { "service", 's', 0, G_OPTION_ARG_STRING,&service,
>                    N_("Search from a specific service"),
>          -         NULL
>          +         N_("SERVICE")

Well, PATH is obvious, but SERVICE - what is that? In some programs we 
add it to the description when using --help so you know of possible 
values. If at the top of every program (that uses SERVICE or LIMIT or 
any of these special upper case words) we had a blurb saying SERVICE is 
either x, y, z, LIMIT is an integer, etc. then that would be fine. But 
if it is just some upper case word, it always leaves me thinking, well, 
what is that then? Is SERVICE and integer, a STRING? It also leaves me 
thinking, why does it say --offset=OFFSET? Of course it is an offset, it 
is the --offset switch - what is the point in repeating the word in 
upper case after the switch unless it is special or indiscriminate.

--
Regards,
Martyn