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:

<Project xmlns="http://usefulinc.com/ns/doap#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:foaf="http://xmlns.com/foaf/0.1/">
  <name>Audacity</name>
  <shortdesc xml:lang="en">
    A fast, cross-platform audio editor
  </shortdesc>
  <description xml:lang="en">
    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.
  </description>
</Project>

13 thoughts on “Translations of package descriptions

  1. If your going to define a spec it should also have a unique identifier for the app/package (guid? uri?) that could then be used by all distros

    …dreaming of a future where we have “click to install app in linux”
    instead of click to install app in “ubuntu, fedora, suse …..”

      • well, there is such a thing called a uniform resource identifier🙂

        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

      • i should add that if rdf is used to store project descriptions, there exists even a transition path for projects (using the turtle notation i suggested below):

        @prefix owl: <http://www.w3.org/2002/07/owl#&gt; .
        @prefix : <http://usefulinc.com/ns/doap#&gt; .

        <http://audacity-project.example/doap#audacity&gt;
        a :Ṕroject;
        owl:sameAs <tag:developer@example.com;2000-05-28:audacity>;

        this states in the project description file that tag:developer@… and http://audacity…#audacity actually mean the same thing / project.

  2. 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.

  3. Brilliant idea, I’ll be happy to submit translations to 12000 upstream projects.
    (not)

    • .desktop files are not enough. Not every project (for example libraries) provides a .desktop file.

      My suggestion is a subset of DOAP. It fits perfectly in our use case.

  4. for doap, i’d suggest to use the turtle rdf format instead of xml, as it is more human readable. the example above would read

    @prefix rdf: .
    @prefix : .
    @prefix foaf: .

    a :Project ;
    :name “Audacity” ;
    :shortdesc “A fast, cross-platform audio editor”@en .
    :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.”””@en ;

    (the stuff is a unique identifier as suggested in the other comment, originally it would be [] for an anonymous resource)

Comments are closed.