StringLane

Report this project’s locales, missing and stale strings, and every validation finding, as the stringlane engine sees them. Reads only; writes nothing. Takes no arguments. The project is fixed when the server starts.

无需输入参数。

Look up what this project already says: one key across locales, or keys matching a search, decoded exactly as the stringlane engine reads them. Use this instead of opening a locale file: four of the five supported formats escape, prefix or nest their values, so the bytes on disk are not the string. Reads only; writes nothing. Takes no file paths. The project is fixed when the server starts.

Report where a translation key is called in this project’s source code, or list the keys nothing appears to call. Use this instead of grepping: it knows the call shapes of each supported framework, matches the spelling the runtime actually uses rather than the merged key, and refuses rather than guessing when it cannot read your code. "Not referenced" is what the scanner SAW, not a verdict. Read the caveat before deleting anything. Reads only; writes nothing.

List exactly the strings that need translating, each with its base value, metadata, placeholders and plural categories, plus the project’s translation context. Returns a planId to pass to validate_translations and apply_translations. Reads only; writes nothing. Takes no file paths. The project is fixed when the server starts.

Check candidate translations against a plan (placeholders, ICU structure, plural categories, length constraints) and report every problem. Writes nothing, anywhere. A clean result means these candidates would be accepted, but it is not permission to write: apply_translations re-runs every check itself and also verifies the project has not changed since the plan was made.

Write validated translations into the project’s locale files. It re-runs every check validate_translations runs, and additionally refuses if the project changed since the plan was made: a clean validate earlier grants nothing. With sourceStamps: true it also writes .stringlane/source-stamps.json and refuses when that file is missing, unreadable, malformed or not a plain file. Either every proposed change lands or none does. Your host asks the user before this runs, and git is where they review what it wrote.

Store a description for one or more keys, so every future translation is made against context instead of a guess. WRITES to your project. A description is stored where this format keeps one: the ARB @key block, an iOS or Android comment, or .stringlane/metadata.yaml. Describing a key that is already translated marks that translation stale, so describe before you translate.

Create the file for a locale this project does not have yet, in the right place and the right format. WRITES to your project. Use this when prepare_translation_plan comes back empty because there is nothing to translate INTO. Never write a locale file yourself: the path, the format and the plural categories differ per project, and a hand-made file skips every check. This creates the FILE. It does not make the app OFFER the language. That lives in the app's own source (a supportedLocales list, Info.plist, a locale config, supportedLngs, a language picker) and each of those is optional per project, so check rather than assume. Do not report a locale as ready before you have.

Store what this product IS, how it should sound, per-locale notes, and words that must never be translated. WRITES to stringlane.yaml. These shape every future translation in every locale, so they are worth getting right once. Omit a field to leave it alone; pass an empty value to remove it.

Add new translation keys and their source strings to the base locale. Use this when you have just written code referencing keys the project does not have yet. WRITES to your project. Send them ALL IN ONE CALL: one call is one atomic write, so a component never ends up half-keyed. Include a description for each key: you are holding the context nobody recovers later, and a key without one is reported by the very next prepare_translation_plan as still needing it. Never add a key by editing the locale file: key names are not equally legal across formats, a description belongs wherever THIS format keeps one, and a hand edit skips both checks. It writes the BASE locale only; every other locale then reports the keys as missing, so translate them with prepare_translation_plan as usual. Adding the key is HALF the job: until those locales have it, the string ships in the base language to everyone else, so do not report the work as done when this returns: localesToTranslate on the result is how many are waiting. A key that already exists refuses the whole set rather than overwriting.

In an i18next project, turn a key the project already has into plural forms in the base locale. Use this for a count_without_plural finding, where a string shows {{count}} but has no plural forms; add_key refuses a key that already exists. WRITES to your project, and there is no preview: the call writes. It replaces the key's current base text with the forms you send, so write every form the base language uses (the finding names them) and keep the placeholders. It writes the BASE file only, and the user reviews the forms in the diff. Send the key exactly as the finding reports it. If owedByLocale on the result lists any locale, those locales now owe forms of their own and prepare_translation_plan offers them; do not report the work as done until they are filled. A key that already has plural forms is refused, and so is a project in any other format.