Re: Call for help (was: Announce of an upcoming upload for the cwidget package)
Hi everyone
David Prévot <taffit@debian.org> wrote:
> The MO files are
> installed [1], but are not used inside aptitude.
Daniel Burrows did some work on this. You will find three commits
from 2011 in the upstream repository[1] all concerning the gettext
infrastructure. This one[2] in particular seems to make effective the
textdomain and is simple enough to clean up (as probably needed) and
incorporate in the NMU.
These updates being unreleased for over a year suggests a lack of
testing. Also, the textdomain is bound to a value hardcoded i18n.h
which should rather be determined by configure.
I have no time today, but during the week can investigate the patches
and the issues I comment on further below.
[1] http://anonscm.debian.org/gitweb/?p=cwidget/head.git
[2] http://anonscm.debian.org/gitweb/?p=cwidget/head.git;a=commit;h=c65caed773bb7604cb2f60fb88ec4d3ed25cfc36
> I've put on hold my NMU intent: there is little point releasing an l10n
> NMU with new translations if they are not displayed, but am still ready
> to prepare all the needed translations once this issue will be addressed
> (not only for the 5 languages already ready in the BTS, but also for the
> 35 others languages currently available in aptitude).
Might I suggest the initial NMU focus on getting the textdomain bound
correctly and the 5 languages on the BTS.
There is also a recently patched issue with widechar prompts[3] that
should also be included.
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316939
After this is working and in the wild, work can proceed with haste to
fill the remaining languages.
Care must be taken that the values for yes_key and no_key are
coordinated with the translations of Yes and No. The first character
of *_key is taken to be the key binding for the corresponding widget.
Some translations in aptitude have completely wrong values for yes_key
(such as mr.po with "हो की कळं"). An incorrect value like that should
not be ported to cwidget, though I suggest that more sensible ones are
(i.e. fr.po with "o" for oui) – it is an area of future work to
support also input methods which can produce non-ascii characters.
IMO any translation without sensible values for both Yes and yes_key
should be omitted at this time.
Aptitude only directly uses yes_key in one place. This is a simple yn
prompt that will be ported to cwidget. All other uses are through
standard cwidget widgets.
Christian PERRIER <bubulle@debian.org> wrote:
> Indeed, David, the translations for Yes/No (and maybe even others)
> could be picked from newt, that has about the same widgets....
Such translations should be compared to those currently present in
aptitude. It does not have "yes" used in widget context, but does
have at least "Ok", "Cancel".
This is a top issue, I will investigate further during the week.
Regards
Reply to: