<id/>

The %{id} is the same name as the installed .desktop file for the application.

<licence/>

The <licence> tag is indicating the content licence that you are releasing the one AppData text file as. This is not typically the same as the project licence. By ommitting the licence value would probably mean your data would not be incorporated into the distribution metadata. Permissible licence codes include:

• CC0
• CC-BY
• CC-BY-SA
• GFDL

<name/>

You can omit this tag if you want the software center to have the same strings as the desktop menu. In some cases it might be required to have a different name in the app-store, but most appdata.xml files will not need this.

<summary/>

You can omit this tag if you want the software center to have the same strings as the desktop menu. In some cases it might be required to have a different name in the app-store, but most appdata.xml files will not need this.

<description/>

The long description is an important part of the file. Important things to consider when writing the application description:

• Include 2-3 paragraphs of interesting easy to read prose.
• Ensure you provide a description of what the application actually does.
• Describe any important features.
• Do not use possily trademarked product names when refering to competitors.
• Break down each paragraph into easily translated paragraphs.
• Use lists sparingly.
• Never refer to installable items as packages.
• Never start the first sentance with This application...
• Try not use more than 100 words.
• Do not be too geeky. Aim for an intelligent semi-technical reader.
• Don't mention what language an application is written in, users don't care
• Only mention what the application can do now, rather than what is planned

Do not assume the format is HTML. Only paragraph, ordered list and unordered list are supported at this time.

<screenshots/>

A screenshot presents your application to the outside world, and could be seen by hundreds or thousands of people.

Screenshots are an important part of how people choose which applications to install, so it's important to get them right. Consistent, good looking screenshots will make your application look more attractive and will expand your userbase. Consistent screenshots also provide a more predictable experience for people using the software center.

Screenshot size, shape and format:

<url/>

Links of type homepage should be a link to the upstream homepage for the application.

<updatecontact/>

AppData is a new standard, and we'll likely be adding extra metadata in the future. If you include the <updatecontact> tag then someone will send an email when the standard is updated, detailing the new fields that you may or may not want to add to your appdata.xml file. We're not expecting to do this more than 4 times a year, so don't expect a deluge of email.

TIP:Use _at_ rather than @ if you're worried about the email address being harvested by spammers.

<project_group/>

If you include the <project_group> tag then this identifies your project with a specific upstream umbrella project. Known values include GNOME, KDE, XFCE, MATE and LXDE, although other umbrella projects like Yorba would make sense too.

NOTE:You should only identify with an umbrella project if you use all their infrastructure and policies, for instance string freezes dates, bugtracker and source control instance.

Questions:

How do I translate this data?

Why not just use the package description?

Different distros cut and join different source packages in different ways, plus, it's not typically translated.

Why not just use the DOAP description?

This is one file per-project and is not suitable when one tarball will install several applications. It's also not translatable.

Why not just use a centralized web service?

Put simply, we don't have the resources to moderate, check and translate each string for every application. We don't have the legal framework so that non-free applications could also ship application data.

The upstream project is in a much better place to describe itself, and the upstream project is able to use it's existing localization and translation teams. Also, things like the screenshot will change as the project is updated, and not all distros ship the same version of an application. We also want the long description to come up immediately, and be searchable, so we can't really use a web service in that case. Additionally, different distros have different policies on trademarks.

What happens if I don't ship this file?

The GNOME Software Center currently shows a nag message that the upstream project doesn't ship the additional data. Additionally, we will penalize apps that do not ship the extra metadata by showing them lower in the search results.

What other data should I include in the file?

At this moment we're trying to do the bare minimum for a software center technical preview. In the future I can totally see this file being used to express what portals are required (i.e. Firefox needs access to your addressbook) and other useful things. I'll update this page when we've got some more concrete use-cases.

Why XML and not JSON/other?

Where will this data be used?

We will scrape this data when building and composing distributions, and depending on the implementation will either use an OCS server or directly copy the AppData data into the AppStream metadata.

What resolution screenshots should I aim to take?

Any 16:9 aspect resolution is fine, as long as the width is at least 624 pixels. A useful table of resolutions of the correct aspect can be found here:

The native size for most software centers is 624x351 and so screenshots taken or cropped to this size will not be resized and will look pixel perfect. The largest resolution screenshot supported is 1600x900.

How do I know if my appdata XML is correct?

You can validate the AppData file using this web helper. Just upload the file you wish to validate:

There are several other ways to validate the data:

Have you got a real world example?