(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:
pgpNyKGTcCxs2.pgp
Description: PGP signature