Re: [Tracker] Updating .po files

[Luca Ferretti <elle uca libero it>]

Il giorno mar, 09/12/2008 alle 14.35 +0000, Martyn Russell ha scritto: 
> 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

That page is for translators, you should read this
http://live.gnome.org/TranslationProject/DevGuidelines ;)

> But from that page and my understanding, 
> our translations contain a lot of old strings which should be
> removed. 

Well, removing depends on maintainer choice, there is no guideline or
rule to respect, in my knowledge. Projects hosted on svn.gnome.org are
using one of the following way: 
      * don't touch PO files - this is the way followed by most project;
        maintainers don't care about not updated translations, this is a
        task for translator itself (better, for translation groups);
        maintainer and developers touch po/ directory only to set it up
        on initial localization support, to update po/POTFILES.[in|skip]
        and sometime to temporary ban from po/LINGUAS a specific
        translation that _breaks_ the build. 
      * update PO files on `make dist` - this is how glib, gtk and atk
        (I don't know if there are other, at least there aren't in
        official GNOME Desktop modules); update is automatically
        performed on `make dist` and new PO files are committed on svn
        at release. But I'm not sure this is exactly a "policy":
        glib/atk/gtk don't use intltool and maybe this force-update
        behavior is inherited by gettext.

As translator, I can say you the glib/atk/gtk policy is not so good if
you (translator) are working on svn checkout: if they release and new
version before your changes are committed, you have a lot of conflicts
to fix, mostly related just to new lines where original strings are
placed.

There are few things that translators could appreciate: string freeze (2
weeks between the last string change and release date), good messages
and comments (no need to scrub the code to understand want a message
really mean).

Summarizing, IMHO updated PO files are neither required, not demanded.

> Doing make update-po should do this as I understand it?

Yes, that rule will update all PO files.

> 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.

OK, I'll try. Meanwhile filed as bug #563875

> > 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.

;) yes, it wasn't the final form. We have two choices here

Number one:
        --limit=NUM    Limit the showed results to NUM (default 512)
        --offset=NUM   Apply NUM as offset showing results (default 0)
        
This style (NUM should be yet used in coreutils and other as NUMBER
abbreviation) is useful to display the kind of agrument (NUMBER,
STRING, ..) but depending on actual option you could repeat it.

Number two:
        --limit=MAX    Limit the showed results to MAX (default 512)
        --offset=SKIP  Apply SKIP as offset showing results (default 0)

This style is not helpful to show the type of the argument, but you can
use different labels for each option.

I suppose you prefer the first. Other options/ideas/comments?

> 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. 

About this: are we fine whit this behavior (print hardcoded(!) services
on --help), or could we add a --list-services option to each tool to
dynamically list services supported by tracker? Do we have a convenience
function to list all services?

OK to file a bug?

> 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.

The message showed by --help is useful for a brief explanation about
usage and to list the **correct syntax**.

If you print out (as tracker is currently doing) something like:

        # tracker-tool --help
        Usage: tracker-tool [OPTION] DIRECTORY
        
        -s, --service    Service to search for       

you are saying that the --service option don't want any argument, i.e.
that `tracker-tool --service ~/Downloads` is valid, while `tracker-tool
--service=Music ~/Downloads` not. This is of course wrong.
        
I don't care so much if we want to print --service=SERVICE or
--service=STRING, but we have to print something :)