<para>
Important news about changes in a package can also be put in
<filename>NEWS.Debian</filename> files.
-The news will be displayed by tools like apt-listchanges, before all the rest
+The news will be displayed by tools like <systemitem role="package">apt-listchanges</systemitem>, before all the rest
of the changelogs. This is the preferred means to let the user know about
-significant changes in a package. It is better than using debconf notes since
+significant changes in a package. It is better than using <systemitem role="package">debconf</systemitem> notes since
it is less annoying and the user can go back and refer to the
<filename>NEWS.Debian</filename> file after the install. And it's better than listing
major changes in <filename>README.Debian</filename>, since the user can easily
translator will send you an update.
</para>
<para>
-To <emphasis>unfuzzy</emphasis> translations, you can use two methods. The first
-method does <emphasis>preventive</emphasis> search and replace actions in the
-PO files. The latter uses <command>gettext</command> utilities to <emphasis>unfuzzy</emphasis>
-strings.
-</para>
-<para>
-<emphasis>Preventive unfuzzy</emphasis> method:
+To <emphasis>unfuzzy</emphasis> translations, you can use
+<command>msguntypot</command> (part of the <systemitem
+role="package">po4a</systemitem> package).
</para>
<orderedlist numeration="arabic">
<listitem>
<para>
-Try finding a complete translation file <emphasis role="strong">before</emphasis>
-the change:
-</para>
-<programlisting>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null --statistics $i; done</programlisting>
-<para>
-The file only showing <emphasis>translated</emphasis> items will be used
-as the reference file. If there is none (which should not happen if you take
-care to properly interact with translators), you should use the file
-with the most translated strings.
-</para>
-</listitem>
-<listitem>
-<para>
-Identify the needed change. In this example, let's assume the change is about
-fixing a typo in the word <literal>typo</literal> which was inadvertently
-written as <literal>tpyo</literal>. Therefore, the change is
-<command>s/tpyo/typo</command>.
-</para>
-</listitem>
-<listitem>
-<para>
-Check that this change is only applied to the place where you really intend
-to make it and <emphasis role="strong">not</emphasis> in any other place
-where the original string is appropriate. This specifically applies to
-change in punctuation, for instance.
-</para>
-</listitem>
-<listitem>
-<para>
-Modify all PO files by using <command>sed</command>. The use of that command
-is recommended over any text editor to guarantee that the files encoding will
-not be broken by the edit action:
-</para>
-<programlisting>
-cd debian/po
-for i in *.po; do sed -i 's/tpyo/typo/g' $i; done
-</programlisting>
-</listitem>
-<listitem>
-<para>
-Change the debconf template file to fix the typo.
-</para>
-</listitem>
-<listitem>
-<para>
-Run <command>debconf-updatepo</command>.
+Regenerate the POT and PO files.
</para>
+<programlisting>debconf-updatepo</programlisting>
</listitem>
<listitem>
<para>
-Check the <filename>foo.po</filename> reference file. Its statistics should
-not be changed:
+Make a copy of the POT file.
</para>
-<programlisting>
-msgfmt -o /dev/null --statistics debian/po/foo.po
-</programlisting>
+<programlisting>cp templates.pot templates.pot.orig</programlisting>
</listitem>
<listitem>
<para>
-If the file's statistics changed, you did something wrong. Try again
-or ask for help on the &email-debian-i18n; mailing list.
+Make a copy of all the PO files.
</para>
+<programlisting>mkdir po_fridge; cp *.po po_fridge</programlisting>
</listitem>
-</orderedlist>
-<para>
-Gettext utilities method:
-</para>
-<orderedlist numeration="arabic">
<listitem>
<para>
-Put all incomplete PO files out of the way. You can check the completeness by
-using (needs the <systemitem role="package">gettext</systemitem> package
-installed):
+Change the debconf template files to fix the typos.
</para>
-<programlisting>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null --statistics $i; done</programlisting>
</listitem>
<listitem>
<para>
-Move all files which report either fuzzy strings to a temporary place. Files
-which report no fuzzy strings (only translated and untranslated) will be kept
-in place.
+Regenerate the POT and PO files (again).
</para>
-</listitem>
-<listitem>
+<programlisting>debconf-updatepo</programlisting>
<para>
-Now <emphasis role="strong">and now only</emphasis>, modify the template for
-the typos and check again that translation are not impacted (typos, spelling
-errors, sometimes typographical corrections are usually OK).
+At this point, the typo fix fuzzied all the translations, and this
+unfortunate change is the only one between the PO files of your main
+directory and the one from the fridge. Here is how to solve this.
</para>
</listitem>
<listitem>
<para>
-Run <command>debconf-updatepo</command>. This will fuzzy all strings you
-modified in translations. You can see this by running the above again.
+Discard fuzzy translation, restore the ones from the fridge.
</para>
+<programlisting>cp po_fridge/*.po .</programlisting>
</listitem>
<listitem>
<para>
-Use the following command:
+Manually merge the PO files with the new POT file, but taking the useless fuzzy into account.
</para>
-<programlisting>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</programlisting>
+<programlisting>msguntypot -o templates.pot.orig -n templates.pot *.po</programlisting>
</listitem>
<listitem>
<para>
-Move back to <filename>debian/po</filename> the files which showed fuzzy strings in the first step.
-</para>
-</listitem>
-<listitem>
-<para>
-Run <command>debconf-updatepo</command> again.
+Clean up.
</para>
+<programlisting>rm -rf templates.pot.orig po_fridge</programlisting>
</listitem>
</orderedlist>
</section>
</para>
<para>
The short description should be kept short (50 characters or so) so that it may
-be accomodated by most debconf interfaces. Keeping it short also helps
+be accommodated by most debconf interfaces. Keeping it short also helps
translators, as usually translations tend to end up being longer than the
original.
</para>
The short description should be phrased in the form of a question which should
be kept short and should generally end with a question mark. Terse writing
style is permitted and even encouraged if the question is rather long (remember
-that translations are often longer than original versions)
+that translations are often longer than original versions).
</para>
</listitem>
<listitem>
If the default value may vary depending on language/country (for instance the
default value for a language choice), consider using the special _Default
type documented in <citerefentry> <refentrytitle>po-debconf</refentrytitle>
-<manvolnum>7</manvolnum> </citerefentry>).
+<manvolnum>7</manvolnum> </citerefentry>.
</para>
</section>
<section id="bpp-i18n">
<title>Internationalization</title>
+<para>
+This section contains global information for developers to make translators'
+life easier. More information for translators and developers interested
+in internationalization are available in the <ulink
+url="&url-i18n-l10n;">Internationalisation and localisation in Debian</ulink>
+documentation.
+</para>
<section id="bpp-i18n-debconf">
<title>Handling debconf translations</title>
<para>
file which is included by all the different translations. This makes it much
easier, for instance, to keep URLs up to date across multiple files.
</para>
+<para>
+Some tools (e.g. <systemitem role="package">po4a</systemitem>, <systemitem
+role="package">poxml</systemitem>, or the <systemitem
+role="package">translate-toolkit</systemitem>) are specialized in extracting
+the translatable material from different formats. They produce PO files, a
+format quite common to translators, which permits to see what needs to be
+retranslated when the translated document is updated.
+</para>
</section>
</section>
<command>apt-cache search .|grep dummy</command> or
<command>apt-cache search .|grep transitional</command>.
</para>
+<para>
+Also, it is recommended to adjust its section to
+<literal>oldlibs</literal>
+and its priority to
+<literal>extra</literal>
+in order to ease <command>deborphan</command>'s job.
+</para>
</section>
<section id="bpp-origtargz">
-<title>Best practices for <filename>.orig.tar.{gz,bz2,lzma}</filename> files</title>
+<title>Best practices for <filename>.orig.tar.{gz,bz2,xz}</filename> files</title>
<para>
There are two kinds of original source tarballs: Pristine source and repackaged
upstream source.
<title>Pristine source</title>
<para>
The defining characteristic of a pristine source tarball is that the
-<filename>.orig.tar.{gz,bz2,lzma}</filename> file is byte-for-byte identical to a tarball officially
+<filename>.orig.tar.{gz,bz2,xz}</filename> file is byte-for-byte identical to a tarball officially
distributed by the upstream author.<footnote><para> We cannot prevent
upstream authors from changing the tarball they distribute without also
incrementing the version number, so there can be no guarantee that a pristine
If a difference arises later (say, if upstream notices that he wasn't using
maximal compression in his original distribution and then
re-<command>gzip</command>s it), that's just too bad. Since there is no good
-way to upload a new <filename>.orig.tar.{gz,bz2,lzma}</filename> for the same version, there is not even any
+way to upload a new <filename>.orig.tar.{gz,bz2,xz}</filename> for the same version, there is not even any
point in treating this situation as a bug. </para> </footnote> This makes it
possible to use checksums to easily verify that all changes between Debian's
version and upstream's are contained in the Debian diff. Also, if the original
that you must remove before uploading.
</para>
<para>
-In these cases the developer must construct a suitable <filename>.orig.tar.{gz,bz2,lzma}</filename>
+In these cases the developer must construct a suitable <filename>.orig.tar.{gz,bz2,xz}</filename>
file himself. We refer to such a tarball as a repackaged upstream
source. Note that a repackaged upstream source is different from a
Debian-native package. A repackaged source still comes with Debian-specific
-changes in a separate <filename>.diff.gz</filename> or <filename>.debian.tar.{gz,bz2,lzma}</filename>
+changes in a separate <filename>.diff.gz</filename> or <filename>.debian.tar.{gz,bz2,xz}</filename>
and still has a version number composed of <replaceable>upstream-version</replaceable> and
<replaceable>debian-version</replaceable>.
</para>
<para>
There may be cases where it is desirable to repackage the source even though
-upstream distributes a <filename>.tar.{gz,bz2,lzma}</filename> that could in principle be
+upstream distributes a <filename>.tar.{gz,bz2,xz}</filename> that could in principle be
used in its pristine form. The most obvious is if
<emphasis>significant</emphasis> space savings can be achieved by recompressing
the tar archive or by removing genuinely useless cruft from the upstream
if you repackage source that could have been pristine.
</para>
<para>
-A repackaged <filename>.orig.tar.{gz,bz2,lzma}</filename>
+A repackaged <filename>.orig.tar.{gz,bz2,xz}</filename>
</para>
<orderedlist numeration="arabic">
<listitem>
Depends: libfoo (= ${binary:Version})
</screen>
</section>
+<section id="bpp-meta">
+<title>Best practices for meta-packages</title>
+<para>
+A meta-package is a mostly empty package that makes it easy to install a
+coherent set of packages that can evolve over time. It achieves this by
+depending on all the packages of the set. Thanks to the power of APT, the
+meta-package maintainer can adjust the dependencies and the user's system
+will automatically get the supplementary packages. The dropped packages
+that were automatically installed will be also be marked as removal
+candidates (and are even automatically removed by <command>aptitude</command>).
+<systemitem role="package">gnome</systemitem> and
+<systemitem role="package">linux-image-amd64</systemitem> are two examples
+of meta-packages (built by the source packages
+<systemitem role="package">meta-gnome2</systemitem> and
+<systemitem role="package">linux-latest</systemitem>).
+</para>
+<para>
+The long description of the meta-package must clearly document its purpose
+so that the user knows what he will lose if he removes the package. Being
+explicit about the consequences is recommended. This is particularly
+important for meta-packages which are installed during initial
+installation and that have not been explicitly installed by the user.
+Those tend to be important to ensure smooth system upgrades and
+the user should be discouraged from uninstalling them to avoid
+potential breakages.
+</para>
+</section>
</section>