Von Computer über Origami und Glaube zu Sinnbefreitem

Menu

Translations of package descriptions

I saw the Translations of package descriptions video from FOSDEM 2010. Every distribution has two translatable string for each package: a synopsis (summary, short description) and a long description. These descriptions differ from distribution to distribution. The descriptions should be shared between the distributions. This will enable us to share the translations of the descriptions.

My idea: Why not letting upstream provide the package description and the translation for it? They should have the knowledge to provide a good description and to update it if required. To encourage upstream to provide the description, we should create a freedesktop specification for it. Quick draft: The tarball should contain a file named package.info. The package.info file should contain three RFC-2822-like fields for each package: Package, Synopsis, and Description. Translation can be stored in package.info.<language> (for example package.info.de).

Example package.info:

Package: audacity
Synopsis: A fast, cross-platform audio editor
Description: Audacity is a multi-track audio editor for Linux/Unix,
MacOS and Windows. It is designed for easy recording, playing
and editing of digital audio. Audacity features digital effects and
spectrum analysis tools. Editing is very fast and provides unlimited
undo/redo.
.
Supported file formats include Ogg Vorbis, MP2, MP3, WAV, AIFF, and AU.

What do you think about this idea?

Edit: Alexandre Franke found an existing markup language designed for our use case: Description of a Project (DOAP). Package is name there, synopsis is shortdesc, and description is description. Here is my example in DOAP:

seriously, there is a number of ways, which are all open as soon as one accepts that every uri can describe a project:
* http uris
+ available to every project
+ can be used to fetch more information on the project
+ has a defined hierarchy, useful for large projects
– often change, especially as long as projects don’t have their own domain
– uri space not under control of the project team when hosted without own domain
* tag uris (rfc 4151)
+ available to everyone with an email addrss
+ time independent — even if the address changes, by the date of coining being included in the uri, its meaning is still defined by the original author
– not resolvable automatically
– afaict not widespread
* uuid uris (rfc 4122)
+ doesn’t reveal too much information (although that’s typically not what you want when publishing a project)
– not really human friendly

remember, when uris are used as project identifiers, every project can choose the uri type it prefers

Could be a problem if different distros split an upstream in different packages. At least some descriptions have ‘this package contains the development libraries’ or ‘documentation for XXX’.

But indeed most upstream could have a core description which would be common to all packages relating to that project. It would not be complete though.
Maybe have some agreed upon flags that signal config files, docs, localisations, examples, shared libs, static libs and any other aspects of a project that can be automatically translated to distro specific messages like
” This package contains the development files.”

Although the biggest issue is I think that fdo originated upstreams or even upstreams that know or care about fdo to bother about such an initiative are a very small fraction of the projects that are packaged in major distros.

So better have distros collaborate on these descriptions instead of expecting upstream to do it. The people most likely to come up with a good cross-distro solution are the packagers and translators themselves.

Upstream should provide only the core description. If a distribution split the upstream project, it should take care of it itself. For example, we split audacity in audacity, audacity-data, and audacity-dbg. We should take the upstream description and add one sentence ”This package contains .”

There is always the possibility to let the packagers write the package.info file and send it as patch to upstream.