Mozilla Fluent FTL localization lets a language express its own grammar without forcing every sentence to follow the source language’s structure. To translate a Fluent .ftl file safely, start by protecting message identifiers and references, then edit the readable text while preserving variables, required selectors and attributes. Parse the file, resolve sample messages through the project’s Fluent runtime, and check the resulting wording in the interface. That short loop is the foundation of fast, accurate Fluent translation.
If you want to know how to translate Fluent FTL files, fix Fluent localization errors, or use Fluent variables and plural selectors, the essential fact is that an FTL resource is more than a list of equivalent sentences. It contains messages, terms, attributes, placeables, references and patterns that may select different language forms. These elements let translators write natural messages for inflected languages, but they also create contracts that must survive an import, edit and export.
This guide explains how to translate Mozilla Fluent messages properly. You will learn where the editable text begins and ends, why a term is different from a normal message, how selectors and plural rules interact, how indentation controls multiline patterns, how to handle UI attributes and markup safely, what to do with missing references, and how to build useful translation QA. The goal is not to make each locale look like English. It is to preserve meaning and behavior while giving each language the room it needs.
A one-minute model of a Fluent resource
Imagine a menu item, a tooltip and a warning about closing tabs. In an older localization system, the application may have separate hard-coded strings that all assume an English noun order and plural choice. Fluent can represent straightforward labels as simple messages while allowing more grammatical structure in a translated warning. The source may remain simple even when a target language needs variants for its own grammar.
In FTL syntax, a message has an identifier and an equals sign followed by a value. The identifier identifies the message to application code. The value is what the user reads after the runtime resolves any embedded expressions. Some messages also have attributes introduced by a period, such as .tooltip or .aria-label, which associate additional text with the same message. Terms resemble messages but are defined with an identifier beginning with a dash, and are meant to be referenced rather than retrieved directly by user-interface code.
A translation workflow should therefore compare structure and intent, not impose raw text equality. Two FTL files can be semantically compatible while the target has different grammatical selectors and sentence arrangements. Conversely, two files can look similar and still differ in a missing variable or attribute that breaks the user’s task. Fluent’s expressiveness is valuable only when the surrounding toolchain respects it.
Trace one message from application to screen
Before editing the full catalog, find a real message in the app and identify its path. Where is the source FTL file? Which Fluent bundle or localization service loads it? What message identifier does code request? Which variables does it supply? Does the app read the message’s value, one of its attributes, or both? What does the finished control look like after formatting?
This path matters because an FTL file can parse successfully while the app requests a missing identifier or sends a variable of the wrong type. Some implementations offer fallback bundles or error recovery. Those behaviors help maintain a usable interface but can conceal incomplete translations if testers only check that text appears. Inspecting the actual input and output provides a trustworthy baseline.
Build a small diagnostic fixture with one simple message, one variable, one term, one attribute and one selector. Render each through the application runtime. When that fixture is understood, it becomes a regression test for new translators, parser updates and translation-management imports. It also gives language reviewers examples of the formatting they must preserve.
Protect message identifiers without restricting word order
A message identifier is an application key. It is usually not a word that should be translated. If code requests account-delete-confirm, changing that key to a target-language phrase prevents the application from finding the intended message unless the code changes as well. The sentence under the key, however, should be free to move clauses, use a different verb construction and choose local punctuation.
Separate this distinction visibly in the editor. Show an identifier as locked context and the message value as editable language. If a vendor tool insists on exposing raw FTL, explain which tokens are identifiers. An error report saying the message account-delete-confirm is missing is far more helpful than a generic syntax failure after an exporter rewrites the file.
When a developer genuinely renames a message, manage it as a source contract change. Update references, translator instructions and target inventories. Do not ask translators to infer the new name from the English sentence. A controlled migration keeps translated wording linked to the correct action and prevents stale messages from being reused under misleading identifiers.
Understand the difference between messages and terms
A Fluent term is a reusable linguistic building block, often used for brand names or words whose forms differ by grammatical context. A term identifier begins with a dash, such as -brand-name. Another message can refer to that term using a placeable. This is not the same as copying a text fragment into every sentence. The reference can carry information and allow the target locale to decide how the term should be expressed.
Suppose a product name is indeclinable in one language but changes form after a preposition in another. Duplicating the same literal name in every translation forces a compromise. A term can be defined with variants or parameterization that support a grammatically appropriate form where the language needs it. The source language does not have to invent the same variation to make that possible.
Terms are generally not intended to be requested directly by application runtime consumers. Preserve their identities and valid references. If an imported translation changes -brand-name to an ordinary message or deletes its leading dash, it changes the model, not just typography. A linter should catch that distinction before the target is deployed.
Reuse terms without creating unnatural language
Reusing terminology supports consistency, but it should not become a demand to use one identical surface form in every sentence. In an inflected language, the same concept may require different cases, endings or articles depending on context. Fluent’s term mechanisms exist partly so these choices can remain within the target localization rather than leaking into source-language application logic.
Create a concept-oriented glossary: what the term means, what it does not mean, where the product uses it, whether it is a protected brand, and which grammatical forms the target locale may need. A translator should not have to reverse-engineer that knowledge from a string key. When the intended concept changes, update the termbase and review dependent messages.
Test term references in complete sentences. A term that looks correct alone can be wrong after a preposition or in a plural construction. If the target language needs a separate form, express it with a supported term mechanism and validate that the surrounding message resolves correctly. The point is reader comprehension and grammatical correctness, not merely reduction in duplicate text.
Placeables connect a sentence to data and other messages
Fluent uses curly-brace placeables to insert variables, terms, message references and other supported expressions. A message might greet a person using a variable called $userName, or include a product name through a term reference. The braces are executable structure. A translator can reposition the resulting phrase, but deleting or misspelling the reference may change what appears in the interface.
Ask developers to document every variable’s type and meaning. A count, amount, person, filename and technical ID are not interchangeable. A person name may vary widely in length; an amount should normally use locale-aware number formatting; a filename may require preserving punctuation exactly. A simple variable name does not give enough context for those choices.
A good QA check compares the source and target variable contract but leaves room for intentional language differences. If a target sentence legitimately omits a repeated name, it may not need the same surface reference, but that decision should be approved in context. For required safety or identity data, omission is not acceptable. The review must distinguish natural simplification from lost information.
Literal braces are not the same as placeables
A technical help message may need to show a literal opening or closing brace. In Fluent, braces have a syntax role, so a raw brace inserted into a text pattern can be interpreted as the start of an expression or break parsing. The Fluent guide illustrates using quoted characters inside placeables to represent literal braces. The exact syntax should be tested with the runtime used by the product.
This is an easy trap for machine translation. A model may preserve every visible word in a developer instruction while changing the escaped brace syntax. The translation looks reasonable in a text editor but the formatter returns the wrong character or reports an error. Keep syntax examples as protected tokens with a rendered preview.
Use separate checks for text that teaches code, text that embeds variables and text that refers to messages. A broad rule to escape every brace can be as dangerous as escaping none. Parse the pattern, format it with test data and compare the resulting displayed punctuation with what the instruction intends the user to type.
Selectors express alternatives inside one message
A Fluent select expression chooses a variant based on a selector such as a numeric variable, a string value, or a supported expression. It is the feature that lets a language supply different grammatical forms without splitting one user action into several unrelated resources. The variant keys identify choices, and the star marks the default variant. The default is necessary so there is a defined response when no explicit choice matches.
Do not treat the variant labels as ordinary translated words. A label may represent a CLDR plural category, an exact number or a programmatic string value. Changing it to a nicer-looking target phrase can change selection behavior. Translators should freely edit the text inside each branch while respecting which branch the application or formatter is designed to choose.
Test with the real value the application passes. A source may provide variants for one and other, while a target locale needs more grammatical categories. The target can add the variants its language requires, provided the expression remains valid and supplies appropriate fallback. A simplistic QA rule demanding identical branch counts would reject one of Fluent’s central capabilities.
Fluent plural categories are grammatical, not simple intervals
A category such as few or many does not have one numerical meaning across all languages. Fluent selectors can follow CLDR plural rules for numeric inputs. Arabic, Russian and other languages may make distinctions not visible in a short English source pattern. A reviewer who checks only the number one cannot determine whether the expression handles the full language.
Construct a test matrix appropriate for each locale. Include zero, one, two, three, five, eleven, twenty-one and larger or fractional values when relevant to the message. The important observation is which variant the runtime selects and whether the displayed sentence is grammatical, not which category an English-speaking reviewer would guess from the number.
When a translator wants a special empty-state message, ask whether it is a content choice for exactly zero or a grammatical plural distinction. Those are different things. Numeric exact-match variants and category-based variants can serve different purposes, and the project should test their interaction. The product’s meaning should remain stable while the target language expresses it naturally.
Parameters and formatting functions belong to the contract
Fluent can use functions for formatting values, with NUMBER and DATETIME among the common built-in concepts in Fluent implementations. A translator may need to format a number to a certain precision or use a grammatical selector that depends on how the number is represented. These are more powerful than plain string interpolation and require correct syntax.
Before changing a function call, find out whether it affects display, grammatical selection or both. For example, forcing a fixed number of decimal places can change the plural rule relevant to a particular language. A date formatter can change the visible order of day, month and year but not the actual event timestamp. Both outcomes need to be verified through the deployed runtime.
Avoid copying arbitrary options from a different Fluent implementation or library version. Validate supported functions and parameter names with the project’s actual bindings. When the source provides data, the target may adapt its display format, but it must not invent a new amount or alter the underlying timestamp. Language freedom and data integrity are complementary requirements.
Attributes keep related interface text together
A Fluent message can have attributes such as .placeholder, .title or .aria-label. This is useful because the text shown on a control, the hint inside an input and the accessible name may express related but not identical meanings. Grouping them under one message identifier lets a translator see their relationship rather than guessing which detached string belongs where.
A target should preserve attributes required by the source application’s contract. If code retrieves the .aria-label attribute and a translation deletes it, the visible control may still work while its screen-reader label disappears or falls back. That failure is easy to miss in a screenshot. Use a structural comparison of the required attribute names and then review the content of each attribute in context.
Do not copy the same target sentence into every attribute merely to fill them. A placeholder may need a short cue, while an aria label may need a specific action and object. A tooltip may explain the effect of a control. Good Fluent localization keeps these texts consistent without treating their purposes as interchangeable.
Use developer comments as translation context
FTL comments can explain a message’s function, variable types and the constraints a reader cannot see from the text alone. A developer may note that $title is the title of a bookmark about to be removed. That information helps the translator choose an appropriate construction and level of seriousness. Without it, the target may confuse removing an item from a list with permanently deleting its underlying content.
Preserve meaningful comments through extraction and review. A translation-management system may strip them as nontranslatable lines, leaving linguists with disconnected fragments. Instead, attach the comment to the correct message or show it in a side panel. If the comment is obsolete, have its owner correct it before it misleads multiple target languages.
Do not publish private instructions, personal examples or unreleased feature names accidentally. Translator comments and user-facing values have different audiences. A packaging check should confirm that the deployed bundle contains intended content and that no explanation has leaked into a message value through a broken import.
Indentation affects multiline Fluent patterns
FTL supports multiline values. In such patterns, the indentation is not arbitrary text decoration; it participates in parsing and in how common indentation is removed from the final value. Copying a paragraph through a tool that strips every leading space, inserts a tab or folds lines differently can change the resource’s structure. A file may remain readable to a person yet no longer contain the intended message.
Start with a simple multiline test. Format the original and target message and inspect the final line breaks and spaces. Do not assume that all visual newlines in the source editor become displayed newlines. The surrounding UI may also wrap text differently. Keep these questions separate: source-format line boundaries, formatter output and widget layout.
When localization tools are involved, test a no-change round trip first. Import a resource containing a multiline message, export it without translating and parse it again. If the output differs in meaning or syntax, fix the filter before sending hundreds of strings to translators. The ability to preserve apparently unimportant indentation is a crucial measure of a safe FTL workflow.
Do not flatten Fluent into a key-value spreadsheet blindly
A plain spreadsheet can be useful for planning, but Fluent is not reducible to one source sentence and one target sentence per key in all cases. A message may contain several attributes, selectors with variants, terms or nested references. Flattening those into disconnected cells can lose context and make a translation impossible to reassemble correctly.
Use a Fluent-aware editor or a translation-management filter that preserves the abstract syntax and presents editable segments with their surrounding structure. The reviewer should see the full message context, including variable declarations, references and branch relationships. If a tool cannot support a target-language variant that was not present in English, it may be unsuitable for Fluent’s asymmetric localization model.
A practical acceptance test is to translate a message with one additional target-language plural branch and a term reference, export it and verify that both features survive. If the tooling discards the extra branch, the translation process is restricting linguistic correctness. Repair that workflow rather than asking every locale to imitate the simpler source message.
Context-specific variants should remain meaningful
Not every select expression concerns number. A product may need different text for a status, an object property or a grammatical feature. When a program passes a value to a select, the value and branch labels form a contract. When the selector is internal to a term, the target language may define the distinction it needs. The two situations should not be conflated.
For an app-controlled status, use stable identifiers and document their possible values. If a state is called pending in code, renaming the variant label to the target-language equivalent is not necessarily permitted. For a language-controlled grammatical property, the translator may need to introduce or rename a target-specific variant. The correct decision depends on who owns that selector and what values it can receive.
Test all expected paths and an unexpected one. Ensure that the default variant remains clear and safe, not misleading. A neutral fallback can be useful when an optional attribute is unknown. A critical status notification may require a stronger guard in code because a generic fallback could conceal an important state distinction.
Preserve meaning in warnings and irreversible actions
Technical validity cannot certify semantic accuracy. A Fluent message can parse, resolve all variables and still tell the user the opposite of what the product intends. Negation, permission scope, retention period, payment state and deletion consequences are especially sensitive. Reviewers should see the preceding step and the action that follows the message.
Imagine a warning that asks whether the user wishes to remove a bookmark. The source might refer only to a saved reference, not delete the underlying page. A target-language translation that uses the equivalent of erase permanently overstates the action. Conversely, a warning about deleting account data must not sound like a harmless dismissal. The distinction is part of the product’s promise to the reader.
Use a brief intent note for each consequential message: action, object, consequence, reversible or irreversible, and the exact choice offered. A translator can then write a natural target-language sentence while preserving the decision. Review the actual buttons and warning as a unit, because individually good translations can contradict one another when placed together.
Make grammatical flexibility a feature, not a loophole
Fluent’s asymmetric design allows target languages to add complexity without forcing the same logic into the source language. That flexibility should improve grammar, agreement, readability and clarity. It should not be used to change product behavior, omit essential obligations or introduce unapproved claims. A different grammatical structure is welcome; a different factual meaning requires product review.
When a target needs extra variants, document why. For example, a noun may require multiple forms according to the count, or a branded term may have a case-dependent form after a preposition. Store the decision in translation notes so future updates do not delete a necessary branch simply because it does not appear in English.
During QA, distinguish semantic equivalence from structural sameness. A locale-specific selector can be correct when the source has none. A missing required accessibility attribute can be wrong even if the main visible message matches. The test suite should encode those different obligations rather than grading every file by superficial similarity.
Test references as a dependency graph
A message can reference another message, and terms can be reused across many locations. This creates a dependency graph. Changing one term can alter dozens of displayed sentences without any individual message file appearing edited. A review limited to changed lines will miss some of the affected output.
Build a reference inventory from the parsed Fluent syntax. When a term changes, identify the messages that depend on it and test representative renderings. Detect missing references and cycles according to the runtime’s behavior. If a reference fails, the formatter may emit a visible fallback or report a resolution error; do not assume the user will see a blank string.
A practical example is a rebranded product term. The new name may require a different grammatical ending in Polish and different article choices in other languages. Validate the term in menus, headings, notifications and error messages, not only where its definition lives. This is safer and faster than a global text replacement across translated sentences.
Handle syntax errors and runtime errors differently
A malformed FTL resource may contain a structural syntax error. A syntactically valid resource can still fail to resolve a missing reference or a variable at runtime. Those problems require different repairs. A parser report should give the file, locale, message and location of the syntax issue. A runtime report should explain what data or reference was unavailable when formatting occurred.
Fluent libraries may be designed to recover from some errors so the interface remains readable. That resilience is beneficial to users, but it can make broken translations appear superficially functional in tests. Configure QA to capture and inspect formatting errors, not merely check whether a string was returned. A fallback containing an identifier is not a successful translation.
Separately record source-bundle fallback. A missing target message can be supplied from another locale depending on the integration. That may be the right emergency behavior but should remain visible in completeness reports. A safety instruction appearing in English in an otherwise localized product may require urgent review even when no exception occurs.
Distinguish FTL parsing from the host application’s markup
Fluent supplies text and structured expressions, while applications may insert the resulting text into HTML, native controls or custom components. Do not assume arbitrary HTML tags in a translation are safe or supported. In a web app, localization may interact with DOM overlays or other markup-aware integrations. The allowed element set and attributes should be defined by the application, not improvised inside target messages.
A link may need to appear in a different sentence position in the target language. If code hardcodes an English substring offset, the wrong words can become clickable. Prefer semantic markup or localized element identification that supports reordering safely. Test both the visual output and actual interaction, including keyboard focus and assistive technology.
Security matters here as well. User-supplied variables must be handled by the relevant renderer with proper escaping and isolation. Fluent patterns should not be treated as trusted HTML merely because they are authored by translators. Define where external data enters, which component escapes it, and how the output is displayed. A translation file cannot replace the host application’s security controls.
Review right-to-left text and mixed-direction data
Arabic and Hebrew patterns may include names, URLs, identifiers and numbers supplied by the app. Mixed-direction text can display punctuation in surprising positions even when the stored logical characters are correct. Fluent implementations may support bidirectional isolation for interpolated variables; the exact feature and configuration should be verified in the host integration.
Test dynamic examples rather than a static Arabic sentence alone. Use a left-to-right email address in an Arabic message, a numeric invoice code, a long Latin product name and punctuation after a variable. Check reading order, copying behavior, cursor navigation and screen-reader pronunciation. Do not insert invisible directional controls casually to make one editor preview look better.
When a problem belongs to the renderer or formatting implementation, fix that layer rather than editing every translation to work around it. Linguists should approve the intended sentence and the placement of variables. Developers should provide reliable bidirectional rendering and safe data handling. Clear ownership improves speed and prevents a temporary workaround from becoming permanent technical debt.
Validate accessibility attributes separately
A message with an aria-label or other accessible text can have a visible value that is fully translated while its accessible attribute is missing. This is a substantive failure because some readers depend on that attribute to understand the control. Include attribute inventories in structural QA and speak the text aloud in target-language screen-reader tests.
Write labels for the action, not merely for the surrounding icon. A button with a trash icon may need Delete selected file rather than a literal description of a bin. A tooltip can explain a feature in more detail than an accessible name. These text surfaces share meaning but have different roles and should be reviewed accordingly.
Check dynamic state changes. A button may announce Paused or Playing depending on application state. A target value that does not change with state can mislead users even if the syntax is valid. Tie accessibility testing to real user journeys and control states instead of validating isolated attribute strings in a catalog.
Quality gates for a Fluent translation pipeline
Gate one checks source completeness and extraction: known resource files, valid identifiers, metadata and clear ownership. Gate two tests the import/export round trip: the tool must retain messages, terms, attributes, selectors and references without unwanted edits. Gate three parses target FTL and checks required contracts. Gate four formats representative messages with realistic variables and records errors. Gate five reviews the displayed language and interaction in the application.
Separate hard failures from review decisions. A missing required message identifier, malformed syntax, unresolved essential reference or deleted accessibility attribute can block release. A long sentence, unusual punctuation or added plural variant may be entirely appropriate and should receive contextual review rather than automatic rejection. Good automation is strict about behavior and flexible about language.
For each defect, report the locale, resource, message identifier, expression or attribute, expected contract, observed output and next action. This saves much more time than a single red status without diagnosis. Over time, classify recurring failures so the tooling prevents them at import or editing time rather than detecting them only at release.
A worked failure: a term loses its leading dash
Suppose an importer edits a shared brand term and exports it without the dash that marks it as a term. The text still looks like an ordinary assignment, but the application’s references expect a term. Messages that refer to the original term may fail to resolve correctly. A translator might try to repair every visible affected sentence, although the actual problem is a single structural change in the shared resource.
Trace the first failed reference. Check the parsed identifiers, compare the target resource with the source inventory, then restore the correct term definition through the authoritative translation file. Format a few dependent messages with sample variables. The repair should happen once at the owner, not through dozens of independent sentence edits.
Add a regression test that imports and exports an FTL file containing an ordinary message, a term, and a reference to the term. If the round trip changes any of their roles, reject the filter. This is a small test with disproportionate value because it protects the consistency mechanism used by the entire localized product.
A worked failure: the source’s English plurals constrain the target
Imagine a team exporting only two branches, one and other, from the English FTL source. A translation platform refuses to let the Polish localizer add a necessary form. The translator either squeezes grammar into the wrong categories or creates manual duplicate strings elsewhere. Both outcomes undermine Fluent’s reason for existing.
Fix the tooling to support target-language variants within the same message. Record the exact selector variable and required default branch. Allow the target to supply the grammar it needs while preserving the application’s numeric input and intended meaning. Validate the output at a range of actual counts.
The central lesson is that structural compatibility does not mean identical branch lists. The tool should verify that the translated resource is a valid, usable Fluent message under the target locale. It should not impose the English source’s limited grammar onto another language.
A worked failure: a tooltip vanishes from the localized build
A form control displays a translated visible label, so a screenshot review approves it. Later, a keyboard user reports that its help text or accessible description is absent. The FTL file contains the main message value but not the source-defined .title or .aria-label attribute. The importer had treated attributes as expendable metadata.
The fix is to restore the required attributes and supply suitable localized wording for each. Then run the application through keyboard focus and screen-reader checks. Compare required attribute names as part of the build. Do not fill them with copies of the visible label unless that is actually appropriate for their role.
This example shows why localization QA must examine the user’s full experience. A resource value that looks correct is not complete if the surrounding component depends on other translated surfaces that were dropped during handoff.
Questions to ask before marking a locale ready
Does every required message exist under the correct identifier? Are terms preserved and usable? Do required attributes appear? Does each select expression have a valid default and correct target-language variants? Do the variables provided by code resolve successfully? Are references valid, and have changed terms been tested in their dependent sentences?
Next ask whether the outputs make sense. Do warnings convey the actual consequences? Are dates and numbers formatted appropriately? Do forms, buttons and accessibility labels describe the intended action? Do right-to-left scripts handle embedded names and identifiers? Do long messages fit and remain understandable under accessible text sizes?
Finally, test failure cases: missing variables, unexpected selector inputs, untranslated entries and a deliberately invalid resource in a controlled environment. Confirm that errors are visible to the localization team and that runtime fallback does not conceal a release blocker. Record which cases are allowed by policy and which require repair.
Frequently asked questions about Fluent FTL
Should FTL message identifiers be translated? Normally no. They are lookup keys used by the application. Translate the value and any user-facing attributes, while maintaining the identifier unless engineers coordinate a migration.
Can a target language have more plural variants than English? Yes. Fluent’s design supports target-language grammatical complexity, including selector branches needed only by that locale. The resource must remain valid and use the provided variables correctly.
What is the difference between a term and a message? A term is a reusable linguistic component with a leading-dash identifier, usually referenced inside messages rather than retrieved directly by the app. A message is a normal localizable unit addressed by application code.
Why does an FTL string look right but not display? Check syntax diagnostics, message and term references, variable values, locale fallback, selected variant and the host application’s rendering. The fault may happen after parsing.
Can I translate .ftl with a generic text editor? You can, but an FTL-aware parser and preview significantly reduce risk. Any tool must preserve indentation, terms, attributes and selectors across a round trip.
Learn more and apply it today
The primary Fluent guides explain the syntax and its linguistic model: https://projectfluent.org/ . For focused examples, see https://projectfluent.org/fluent/guide/terms.html , https://projectfluent.org/fluent/guide/selectors.html , https://projectfluent.org/fluent/guide/attributes.html and https://projectfluent.org/fluent/guide/placeables.html . Check the specific runtime binding used by your product when implementing parsing and error handling.
Continue with the translation QA series at https://edukatesg.com/how-people-translate-quickly-series-index/ and the wider Master Art of Translation at https://edukatesg.com/2026/09/18/master-art-of-translation-complete-system-moving-meaning-between-languages/ . Related engineering guidance includes https://edukatesg.com/2026/09/19/how-people-translate-quickly-icu-messageformat-plurals-selects/ and https://edukatesg.com/2026/09/19/how-people-translate-quickly-localization-build-validation/ .
Begin with a small Fluent resource containing an ordinary message, a variable, a reusable term, an attribute and a numeric selector. Import it into the intended translation workflow, write a natural target-language version, export it, parse it and render every case with sample data. If the target needs a grammatical branch absent from English, add and test it rather than suppressing it. Repeat the same checks at scale, and multilingual releases become both more human and more dependable.