README

English messages for meraki/schema.

Data, not code. This package contains two files — en.mfr and en_AU.mfr — and no PHP at all. That is deliberate: they are ICU MessageFormat 2 resources, so a Rust or JavaScript implementation of meraki/schema reads exactly the same wording. A sentence is written once and rendered identically wherever the schema is used.

Using it

composer require meraki/schema-language-english:dev-main

dev-main while meraki/schema is in alpha: this pack tracks the library's vocabulary, which is still moving, so there is nothing stable to pin to yet. It gets a version of its own — not the library's — once meraki/schema reaches a real release.

use Meraki\Schema\Definition;
use Meraki\Schema\Message\Mf2\Mf2Provider;

$provider = Mf2Provider::fromPackage('meraki/schema-language-english');

$schema = new Definition('signup');
$schema->add($schema->createAddressField('billing', ['AU']));

$result = $schema->validate($data, locale: 'en-AU', messages: $provider);

$result->forField('billing')->messages->forPart('postal_code')->first;
// "That is not a valid postcode for the country you chose."

To change a sentence without forking this package, lay your own directory over it — a later pack overrides an earlier one entry by entry:

Mf2Provider::fromPackage('meraki/schema-language-english')
    ->withPack(__DIR__ . '/../resources/lang');

What is in here


`en.mfr`	the base: a sentence for every failure the library reports
`en_AU.mfr`	Australian English — four words that differ, and nothing else

en_AU.mfr is short on purpose. It redefines part.postal_code as postcode, and every message that mentions one follows, because those messages say {$part} rather than spelling it out. A variant that stays this short is a variant working properly.

Note what does not belong in en_AU.mfr: this is the language a reader speaks, not the country an address is in. An Australian reader can be entering a New Zealand address.

Checking it

composer install
composer test

which is schema-lang validate . --strict — the linter that ships with meraki/schema. Since this package has no code, that is what stands in for a compiler. It reads the vocabulary off the library's own classes, so it cannot go stale, and it catches a message using an unimplemented MessageFormat feature, a key the library never asks for, and — the one that matters most — a message naming a variable nothing will fill, such as {$minimum} where the library supplies {$bound}.

--strict adds the fourth: a key the library does ask for that this pack has no wording for. Without it an incomplete pack exits 0, which would let a constraint added upstream land here silently — the opposite of what the weekly run is for.

schema-lang keys lists every key a pack may define and the variables each may name.

Writing another language

Copy the structure: a repository with .mfr files at the root, one per locale, @locale at the top of each, and a composer.json with no autoload section. Then wire the same check into CI.

The four variables are {$field}, {$kind}, {$part} and {$bound}, and they arrive already in your language — {$kind} and {$part} resolve through the kind.* and part.* entries you define, and a list-valued {$bound} is joined using your own list.separator and list.lastSeparator.

Full instructions are in docs/MESSAGES.md.

Development

meraki/schema is a dev dependency, pulled from Packagist as dev-main — the library ships the schema-lang linter that checks this pack, and reads the vocabulary off its own classes.

dev-main rather than a tagged constraint while 2.0 is in alpha, deliberately: the vocabulary is still moving, and CI runs weekly so a constraint renamed upstream shows up here without waiting for somebody to edit a message. Swap to ^2.0 once the keys stop changing.

License

MIT.

meraki / schema-language-english

Package info

Security

Statistics