Re: dpkg accelerators

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: dpkg accelerators

Christian Perrier
Quoting Clytie Siddall ([hidden email]):

> Hi everyone :)
>
> I'm reviewing my dpkg translation (which is taking much longer than  
> I'd anticipated), and I'd like to be able to set some more intuitive  
> accelerators.
>
> In the set of strings beginning:
> ____
> #:dselect/main.cc:138
> msgid "a"
> msgstr "a"
>
> #:dselect/main.cc:138
> msgid "[A]ccess"
> msgstr "[A]Truy cập"
> ____
>
> Can I change the character selected in the original strings?


Frankly speaking I would not recommend spending too much time on
dselect translations, except for the sake of being 100%.

I even wonder whether we should split the PO files in two domains:

-dselect strings-->keep existing translations and stop being active in
promoting new translators to work on them

-other strings-->still need translations and only include these in
"d-i level 4"

dselect is mostly abandoned software. We keep it in Debian because
this is the historical software selection tool. But Debian newcomers
are dropped into aptitude now, so the dselect prevalence is slowly
decreasing (this week, I convinced my boss to stop using it...yay!)

I think that we will probably propose to completely abandon dselect
after etch release. I don't know about the feelings of other dpkg
maintainers whose advice has much weight than mine but the former
maintainer of dpkg mentioned he would never touch dselect anymore
several times....



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: dpkg accelerators

Nathanael Nerode-5
Christain Perrier wrote:
>I think that we will probably propose to completely abandon dselect
>after etch release.

Please don't.  Some of us are very happy with dselect and still don't consider
aptitude a usable replacement.

If dselect ever manages to get broken out into a separate source package from
dpkg (a very good goal), I would totally take it over.  I haven't been able
to figure out how to detangle it from dpkg, however, so I haven't done so.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: dpkg accelerators

Christian Perrier
Quoting Nathanael Nerode ([hidden email]):

> Christain Perrier wrote:
> >I think that we will probably propose to completely abandon dselect
> >after etch release.
>
> Please don't.  Some of us are very happy with dselect and still don't consider
> aptitude a usable replacement.
>
> If dselect ever manages to get broken out into a separate source package from
> dpkg (a very good goal), I would totally take it over.  I haven't been able
> to figure out how to detangle it from dpkg, however, so I haven't done so.


At least, I'll try to get someone working on removing dselect strings
from the main dpkg PO file and move them into another PO file with the
goal "don't waste translator's time"....:)


Anyway, is there a reason for you not joining the dpkg team,
Nathanael...and thus maintaining dselect inside dpkg in the meantime?



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]