Here we define some guidelines for when creating new sounds that extend the standardized list of sound names defined here, in order to provide sounds for more specific events and usages.
Sound names are in the en_US.US_ASCII locale. This means that the characters allowed in the sound names must fall within the US-ASCII character set. As a further restriction, all sound names may only contain lowercase letters, numbers, underscore, dash, or period characters. Spaces, colons, slashes, and backslashes are not allowed. Also, sound names must be spelled as they are in the en_US dictionary.
The dash “-” character is used to separate levels of specificity in sound names. For instance, we use “search-results” as the generic item for all search results, and we use “search-results-empty” for an empty search result. However, if the more specific item does not exist in the current theme, and does exist in a parent theme, the generic sound from the current theme is preferred, in order to keep consistent style. From left to right the words in a sound name become more specific. In some cases what word in a name is more specific is ambiguous. (i.e. "dialog-error" and "error-dialog" both make sense, the former would ease defining the same sound for all dialogs popping up, regardless of its context, the latter would ease defining the same sound for all errors, regardless of how it is presented to the user). In such cases it is generally preferred to put the UI element noun left -- if there is one --, however exceptions of this rule are acceptable.
Sounds for branded applications should be named the same as the binary executable for the application, prefixed by the string “x-”, to avoid name space clashes with future standardized names. Example: “x-openoffice-foobar”.
Please send suggestions for new standardized names to the XDG mailing list: