Re: [Tracker] Updating .po files

[Martyn Russell <martyn imendio com>]

On 09/12/08 17:00, Luca Ferretti wrote:
> 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.

Sure, but that is the same for coders too - if you change white spacing 
with a script at the wrong time, or I suppose any time when you make 
large changes which are superficial.

Fixes should always be applied as quickly as possible to avoid bit-rot.

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

Well, this is partly what Ivan and I are thinking. As part of the up and 
coming release, we would announce to the mailing list that translators 
need to commit any final patches and then when we release, we update the 
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

Sweet, thanks.

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

Of course :)

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

We don't. But that's something that all utilities could use - perhaps we 
need some shared source there. I certainly think --list-services would 
be a good idea. For some tools which require a service it makes sense to 
print them in the description, for others, it makes sense to have a 
command line argument to get a list.

> OK to file a bug?

Sure.

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

Yes, I realise that now actually. Good point.

> I don't care so much if we want to print --service=SERVICE or
> --service=STRING, but we have to print something :)

I see. Then we should fix those yes.

--
Regards,
Martyn