[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

DEP-4: The TDeb specification.



(No need to CC: me on either debian-devel or debian-i18n, thanks.)

Time to launch the debate on the Draft TDeb Specification - DEP-4.

Current HTML form: http://people.debian.org/~codehelp/tdeb/

SGML form for modification: svn://svn.debian.org/dep/web/deps/
(Draft.sgml - please notify me if the SGML is modified so that I can
update the HTML generated from the SGML.)

DEP form: http://dep.debian.net/deps/dep4/
(not yet fully automated from SVN commits, hence not yet the preferred
form for modification - can be mostly generated from the SGML.)

Date: March 2009
Drivers: Neil Williams <codehelp@debian.org>
 Joerg Jaspert <joerg@debian.org>
 Thomas Viehmann <tv@beamnet.de>
 Mark Hymers <mhy@debian.org>
 Frank Lichtenheld <djpig@debian.org>

Abstract: This document provides an overview of the TDeb format, TDeb
 design and usage. This specification should be considered as a work in
 progress. 

Purpose: The aim of the DEP is to improve and ratify sufficient
portions of the specification to allow Squeeze to be released with
support for TDebs in core packaging tools, ready for the creation of
the first TDebs in Squeeze+1. 

Primary focus: Tool support in Squeeze. Initially, only debconf
translations will be targeted for TDebs in Squeeze+1 - package
translations for native packages should also be possible in Squeeze+1
but other translations are not likely to be implemented until 
Squeeze+2. Please keep the DEP concentrating on the tools, not the later
implementation. There will be time to improve support in Squeeze+1 for
corner cases arising from packages looking for TDebs in Squeeze+2.

Primary Motivations (in order):
   1. Updates to translations should not require source NMU's.
   2. Translation data should not be distributed in
architecture-dependent packages.
   3. Translators should have a common interface for getting updates
into Debian (possibly with automated TDeb generation after i18n team
review).

Secondary Benefits:
   a) users will be able to selectively install package localisation
according to the supported locales on individual machines and Debian
will keep all such selective installations updated automatically,
including adding/removing translations for existing packages when the
locale configuration is modified.
   b) easier, quicker and more thoroughly
reviewed translations of debconf, native package strings and other
translations.

Resources:
 i:
http://meetings-archive.debian.net/pub/debian-meetings/2009/fosdem/slides/TDebs_draft_specification/tdeb-fosdem-2009.pdf
 ii:
http://meetings-archive.debian.net/pub/debian-meetings/2009/fosdem/low/TDebs_draft_specification.ogg 
 iii:
http://meetings-archive.debian.net/pub/debian-meetings/2009/fosdem/high/TDebs_draft_specification.ogg

Code: git://git.debian.org/git/users/tviehmann/dpkg
git://git.debian.org/git/users/codehelp/debhelper

ToDo: +t1.diff.gz support - i.e. allowing dpkg and apt to look for and
apply the changes made by translators - only some elements of this need
to be implemented in Squeeze. apt also needs to understand locales and
download the relevant TDeb alongside the package so that
apt-extracttemplates can offer translated debconf questions upon first
installation.

Other packages: reprepro, langupdate (in NEW), ...

Limitations: At this stage, there is no need to discuss the finer
points of TDebs as they pertain to implementations not possible until
*after* the release of Squeeze, EXCEPT where those points have a direct
bearing on how tools like dpkg and apt handle tdebs in the
Squeeze->Squeeze+1 migrations. For this reason, there doesn't need to
be any definitive agreement about how TDebs will work with upstream
translations, KDE or non-gettext translations or anything else relating
to the actual use of TDebs after Squeeze during the ratification of
DEP-4 itself.

Relation to Emdebian: Emdebian has thousands of TDebs with a slightly
different emphasis - although you are welcome to use the
http://www.emdebian.org/locale/ repository as a test case, bear in mind
that Debian TDebs will differ internally and in numbers. Note also that
reprepro needs to support TDebs - it currently forces a renaming
to .deb - a bug report will follow in due course.

Numbers: The DebConf8 and Extremadura meetings established that the
number of TDebs does need to be careully managed, therefore TDebs will
be architecture-independent and source-package based. Some TDebs will
be very, very small - others could be quite large indeed. There is
scope in the specification for multiple TDebs where source packages
have debconf support and large amounts of translated documentation.

Policy: Elements of DEP-4 can be migrated into Policy discussions and
patches in due course - how that is actually done is up to maintainers
of debian-policy. 

Discuss.

:-)

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgpg_iGG180Ez.pgp
Description: PGP signature


Reply to: