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
_______________________________________________
tracker-list mailing list
tracker-list@gnome.org
http://mail.gnome.org/mailman/listinfo/tracker-list
