Gettext MO — Portuguese (Brazil)
Compiled gettext MO binary for Portuguese (Brazil) — pair with the matching PO for loader tests.
| field | value |
|---|---|
| format | gettext MO |
| locale | pt-BR |
| messages | 7 |
Specifications
- Locale
- pt-BR
- Format
- gettext MO (compiled)
- Messages
- 7
Testing contract
Expected to recover- Scenario
- Inspect this legacy compiled message catalog using explicit UTF-8 decoding and compare it with the corrected P9 compiled catalog.
- Expected result
- Seven translations are present, but the legacy MO has no empty metadata header declaring its charset and its original message IDs are unsorted. Descriptor enumeration with explicit UTF-8 recovers the messages; readers assuming ASCII or binary-search ordering can fail. Use the versioned corrected MO for normal gettext loading.
What is a .mo file?
A MO file (.mo, Machine Object) is the compiled binary form of a gettext PO catalog used at runtime by gettext libraries. It stores msgid/msgstr pairs in a compact hashed table for fast lookup.
How to use this file
Use an example .mo file to test gettext runtime loaders, MO parsers, and PO↔MO conversion tooling.
How to use this file for testing
“Gettext MO — Portuguese (Brazil)” is a deterministic Novus Examples fixture for Internationalization. Parallel text and accented, multi-script content, for testing translation pipelines, Unicode handling, and localization tooling.
Documented properties for this file: 7 messages · gettext MO (compiled). Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such, expect parsers to fail loudly rather than silently accept them.
Translation-catalog fixtures carry the same message set across formats, each with its native placeholder syntax. Test your i18n loader, catalog converter, or translation-memory tool, and use the RTL and CJK variants to check bidirectional text and Unicode handling.
Load the catalog with your i18n framework and verify placeholder interpolation and plural handling; the RTL and CJK variants exercise bidirectional text and font fallback.
Code examples
import gettext
with open("app_pt-br.mo", "rb") as f:
cat = gettext.GNUTranslations(f)
print(cat.gettext("Hello")) # .mo is the compiled catalogRelated files
- pogettext Catalog — Spanish (.po)A translated gettext .po catalog (Spanish) with a full header, source-location and translator comments, c-format flags, and a plural-form entry — for testing PO parsers and translation-memory tools.
- moGettext MO — FrenchCompiled gettext MO binary for French — pair with the matching PO for loader tests.
- moGettext MO — GermanCompiled gettext MO binary for German — pair with the matching PO for loader tests.
- moGettext MO — KoreanCompiled gettext MO binary for Korean — pair with the matching PO for loader tests.
- mogettext MO with Plural-Forms — Arabic (compiled)The compiled Arabic MO twin. Plural entries are encoded the way msgfmt does it — the original is 'singular\\0plural' and the translation is the 6 forms joined by NUL — and the header entry carries the Plural-Forms expression, so ngettext resolves without the .po file present.
- mogettext MO with Plural-Forms — Polish (compiled)The compiled Polish MO twin. Plural entries are encoded the way msgfmt does it — the original is 'singular\\0plural' and the translation is the 3 forms joined by NUL — and the header entry carries the Plural-Forms expression, so ngettext resolves without the .po file present.
Generated by generation/localization_wave_c.py. Free for any use, no attribution required, license.