cldr-emoji-annotation

Overview

cldr-emoji-annotation packages CLDR emoji annotation data for use in a Linux distribution. CLDR is the Unicode Common Locale Data Repository, which provides locale-related data used by software that needs consistent language and character information. In this package, the relevant part is the emoji annotation set: short names and search keywords for emoji characters and sequences. (cldr.unicode.org)

This package exists so downstream users can consume the upstream CLDR annotation data in a packaged, reproducible form rather than pulling files directly from the upstream source tree or release artifacts. The repository is primarily useful to maintainers who need to rebuild, review, or update that data in NiceOS. (github.com)

Purpose and typical use cases

Typical use cases include:

• localization and language data workflows that need emoji names or keywords;
• software that builds search, picker, or lookup interfaces for emoji;
• desktop or application components that display user-facing labels for emoji;
• translation or data-maintenance tasks that track CLDR annotation content.

Typical users include:

• distribution maintainers packaging Unicode or localization data;
• developers integrating CLDR-derived annotations into applications;
• localization engineers and translators reviewing character labels;
• CI/CD maintainers who validate source refreshes and package rebuilds.

The package is not a standalone application. Its practical role is to carry upstream data in a form suitable for RPM-based distribution. That role is inferred from the package summary and the upstream CLDR documentation, but NiceOS maintainers should verify the exact downstream consumers before relying on it for any narrower claim. (cldr.unicode.org)

Upstream project

Upstream is the Unicode CLDR project. The official CLDR site documents emoji names and keywords as part of CLDR character data, and the project publishes release material through Unicode and the CLDR GitHub organization. (cldr.unicode.org)

Useful upstream references:

• CLDR home and documentation
• CLDR emoji names and keywords documentation
• CLDR release notes

If NiceOS needs to confirm a specific data-generation rule, file layout, or release process, verify it against upstream documentation before updating this package. (cldr.unicode.org)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic.
• SOURCES/ — source metadata and manifests used to track imported upstream content.
• METADATA/ — repository metadata used by the packaging workflow.
• SBOM/ — software bill of materials material, when maintained for this package.

The repository intentionally does not store large upstream source archives in Git. Instead, source integrity is tracked through manifest files in SOURCES/. That keeps the repository small while still recording which upstream content the package is expected to use. Do not treat the absence of archive files as missing data; it is part of the packaging policy. (github.com)

Source storage and integrity policy

NiceOS maintains source tracking through the files in SOURCES/. The expected workflow is to record imported upstream material in the manifest, rather than committing the full archive into the Git repository.

Before using updated sources, verify:

• that the manifest entries were refreshed intentionally;
• that the imported upstream content matches the intended CLDR release or snapshot;
• that no unexpected files were added, removed, or renamed;
• that any generated package metadata still reflects the current upstream layout.

This README does not print concrete hashes or archive names. Those values can change on every upstream refresh and should be checked in the repository state or build pipeline instead.

NiceOS maintenance notes

Before updating the package, NiceOS maintainers should check:

• whether the upstream CLDR data layout for emoji annotations has changed;
• whether the spec file still points to the right source metadata and installed paths;
• whether SOURCES/ needs regeneration because imported files changed;
• whether SBOM/ needs to be refreshed to match the new packaged content;
• whether any downstream patching still applies cleanly;
• whether the update changes filenames, generated outputs, or packaging assumptions.

Risks to consider:

• upstream data structure changes can break generation or install steps;
• regenerated files may differ in ways that affect comparisons or QA;
• package consumers may depend on file paths or naming conventions, so those should be checked carefully before any rename or layout change;
• if a source refresh is done from a new upstream snapshot, confirm that the intended CLDR content was selected and not a partial or accidental extraction.

If any of these points are unclear, NiceOS maintainers should verify them against the current upstream sources and packaging scripts before merging an update.

Build and verification checklist

For RPM maintenance, a practical checklist is:

• confirm the spec file still builds with the current source manifest;
• verify SOURCES/ reflects the desired upstream content;
• check that %prep, %build, and %install steps still succeed;
• inspect installed file locations for unexpected path changes;
• compare generated package output against the previous build for unintended drift;
• run any available package tests or file-level sanity checks;
• review the SBOM material if the repository maintains one for this package;
• confirm license packaging still matches the declared Unicode license terms;
• ensure no unexpected generated files were introduced into the Git repository.

If the package is used by other CLDR-based components, verify those consumers against the updated data before publishing the build.

References

• Unicode CLDR
• Emoji Names and Keywords
• CLDR 38 Release Note
• Unicode CLDR releases

Russian documentation

See README_RU.md.

Dist-git repository notes

• Package repository: rpms/cldr-emoji-annotation
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.