Drupal interface translation becomes much easier when the editor knows which Drupal layer owns the sentence. Readers searching Drupal interface translation, Drupal Locale module, import PO translations Drupal, or Drupal multilingual interface not translating are usually trying to make a navigation label, administration control or module-provided message appear in another language. The challenge is that a Drupal website can also contain translatable content and configuration, and those are not the same workflow as translating the program’s interface strings.
A Drupal page can display a translated navigation command, an English title written by an editor, a translated field label stored as configuration, and a custom-module message supplied through the interface translation system. To a visitor they are all simply words. To a site builder they may come from different data stores, source files, language-negotiation settings and permissions. Editing the wrong translation layer can leave the target page unchanged or, worse, create an inconsistent multilingual experience across routes.
This guide owns one reader job: find, import, review and validate interface-string translations on a modern Drupal site using the core Interface Translation (Locale) functionality and its gettext PO workflow. It explains how to distinguish interface text from content and configuration, how to identify context, how language selection affects display, and how to test imported strings without harming site behaviour. It does not teach wholesale translation of articles or an entire multilingual site architecture. The focus is the site interface shell and custom module messages.
Quick answer: decide which layer owns the phrase before importing anything
Enable and configure the relevant Drupal multilingual modules for your supported release, including Language and Interface Translation where appropriate. Add the target language. Identify the phrase as an interface string rather than article content or a configuration label. Use Drupal’s supported interface translation tools to search and edit strings or import a compatible .po file. Verify the target language actually selected by the request, then view the page as its intended audience. Check buttons, paths, help text, plural forms, placeholders and any custom module screens affected by the translation.
Do not reach first for a giant PO file when the only required change is one local button phrase. Drupal’s interface translation UI can be more precise for a small override. Conversely, do not hand-translate hundreds of standard Drupal strings when established community translations for the selected language are available. The source, scale and maintenance owner should determine the method. Importing a third-party PO file without checking version and origin can create more questions than it answers.
A clear acceptance contract might say: “With French selected, an anonymous visitor sees the supported contact-form interface messages in French while the submitted form data, route destinations and author-written page body remain unchanged.” This is a testable goal. “Make this site French” is too ambiguous because it can mean interface language, translated configuration, translated editorial content, language negotiation, or all of them. The smaller definition lets a team solve the actual reader’s problem first.
Drupal uses several language systems for different jobs
Drupal core separates language management, interface translation, content translation and configuration translation. The Language module lets a site define languages and negotiate which language is appropriate in a request. The Interface Translation module, also called Locale, deals with strings used by code and modules for the interface. Content Translation supports translatable content entities such as appropriate pages, taxonomy terms or blocks. Configuration Translation supports eligible configuration text such as field labels or Views-related settings. The exact set of modules and interfaces should be checked against your Drupal version and installed extensions.
This division is not merely organisational. If a news article title remains English, importing an interface PO file will not automatically create a French version of the article. If a custom field label belongs to configuration, changing an unrelated code string may not change it. If the word “Save” appears on an administrative button, translating the entire content entity is an unnecessarily broad response. Different layers protect different kinds of ownership and state.
Draw a source map for a target page before editing: site shell and code strings, configuration labels, authored content, user-generated data, and external embeds. Then put a boundary around the interface strings included in this release. This map helps translators know what they may change and helps testers avoid false failures. A site can be partially multilingual by design; the goal of a specific interface translation job is not to claim complete language coverage where other content systems have not been configured.
How the Locale module finds interface text
Drupal interface messages generally originate from translatable strings exposed by core or extensions. Core translation mechanisms allow code to request a target-language value for an identifiable source phrase, subject to language context and translation availability. The Locale module collects or imports strings, and translations can be supplied through Drupal’s interface, updates or gettext PO files. The server selects a translation for the current interface language when it renders the message. The text in a PHP or Twig template may be part of the source, but the user sees the resolved value, not the underlying lookup process.
This creates a responsibility split. A developer must expose the message through the appropriate API rather than hard-code English into output. A translation maintainer must supply the target value for the right string and context. A site builder must configure language negotiation so the page uses the intended target language. A tester must verify actual rendering. If any one of these fails, the page can remain partly English even when the translation file looks complete.
It helps to think of translation as resolving an address. The source phrase or its context identifies a request, the selected interface language chooses the target catalogue, and the rendering system displays the result. A visible word alone is not enough to establish the address. Two source strings can look the same but serve different features. When one phrase is missing, test the chain from source exposure to imported value to selected language before deciding the translation itself is defective.
Begin with a staging snapshot and one reproducible page
Record the Drupal core version, installed relevant modules, target languages, active theme and any custom extension that generates the text. Work in a staging environment when changing high-impact navigation or transaction wording. Use a known page with a stable route and a test account whose role matches the real audience. Document the current interface language selection mechanism: path prefix, domain, user preference or another configured method. You cannot interpret language-test results without knowing which input Drupal uses.
Capture the exact English phrase and its surrounding action. Is it a submit button on a form, a status message after saving, a menu link, a field label, or a screen heading? The visual proximity of text does not prove common ownership. A form can contain a code-generated error plus a configuration label plus content copied by an editor. Identify the part you are authorised to translate. Keep source route names and technical references separate from display text; a translated label should not automatically change the target of a link.
Before importing, back up the relevant configuration and record the current translation state. Use your team’s supported database and configuration backup practice rather than editing the live database directly to create an unofficial shortcut. A rollback should be specific: which PO file or local translation entries were added, what language they targeted, and how the earlier state can be restored. A small, well-documented change is much easier to reverse than an untracked bulk import applied to a busy site.
Find out whether the translation already exists
Drupal has community translation infrastructure, and the Locale module can work with downloaded or locally imported interface translations. Before commissioning a new translation for a common Drupal interface phrase, check whether a suitable reviewed target exists for the relevant core or extension version. Reusing legitimate community work avoids typing and gives access to terminology that translators have already discussed. Nevertheless, a downloaded pack is not proof that every custom module string on your site will be covered.
Check the source of the file and the version it is intended to support. A PO file for an old Drupal release may refer to strings that no longer exist or miss newer messages. A translation for a different extension or locale may contain plausible phrases that are not appropriate for your site’s audience. Importing an entire file to solve one missing string can have a wide blast radius. When possible, scope the import to the correct project and language; afterwards, inspect existing local overrides that should not be unintentionally replaced.
If a phrase has no published translation, decide whether to contribute upstream, add a site-level interface translation, or ask the module maintainer to expose the phrase properly. These are different jobs. A private brand-specific term may belong in your site’s customisation layer. A genuine mistake in a widely used interface string could justify a community contribution. A hard-coded message requires a code change before any catalogue can translate it. The correct route is the one that matches ownership.
Understand a PO file before editing its messages
A gettext PO file consists of entries that pair source messages and target translations, often accompanied by comments, references, context or plural forms. msgid carries the source message and msgstr the target value. Some entries also have msgctxt or plural-related fields. Do not treat a PO file as free-form prose. The structure determines what gets imported and how target messages are selected. Editing a source identifier as though it were a label can sever the relationship with the string Drupal requests.
A simplified instructional example is:
msgid "Return to the form"
msgstr "Revenir au formulaire"
This French target might be sensible for a link that takes a visitor back after an invalid submission, but should not be approved without observing the actual route. “Return to the form” could also mean return to an unsent draft from a review screen. The translator needs to know whether form data is preserved and what the link does. A grammatical translation that promises to preserve input when the link resets the form would be unsafe. The catalogue does not contain the entire user journey.
Use a PO-aware editor and keep required syntax intact. Be cautious when importing files edited in ordinary spreadsheet software, which can disturb quoting, escaped line breaks or multiline values. Validate the catalog before import; then verify it in Drupal. A file that parses correctly can still contain a misleading message. That is why structural validation and contextual linguistic review are separate steps, with distinct reviewers when the project is consequential.
Worked example: a contact form’s “Send” and “Cancel” controls
A civic organisation’s Drupal site supports English and French. Its contact form has a “Send” button, a “Cancel” link, and a confirmation message. A translator proposes the most common French equivalents. The site builder checks what “Cancel” does on this implementation. Does it navigate back to the home page, reset the form, close a modal, or discard a saved draft? Each action could require a different target instruction. The English source may not be precise enough, and translation review can reveal the ambiguity.
The team identifies which values are code interface strings and which are configured form labels. If the “Send” control is owned by a form configuration or extension, translate through its actual surface. If the success message is a core or module interface string, use the Locale pathway. The scope is documented in two rows rather than flattened into one list because each item has different ownership. The reviewer writes down the expected outcome after pressing each control.
In a staging site, a French test user completes the form with fictional details. They submit a valid message and inspect the confirmation; then they return and trigger a validation error using empty required fields. The target messages must explain what happened, not imply that a message was sent when it was rejected. The team checks keyboard navigation and screen-reader labels. An accurate visible translation is necessary, but a form is complete only when its interactions remain understandable.
Worked example: an English source word with two possible meanings
A custom Drupal module uses the button “Close”. In one interface, it dismisses a pop-up without changing stored information. In another, it closes a service ticket, causing a workflow status change. A translator could use one target word for both if the target language supports it, but should not assume that is always clear. The action must be evaluated from context. Technical matching of source phrases is not the same as functional equivalence.
Ask the developer whether the two strings use separate contexts or identities. If not, and different translations are necessary, the source implementation may need more precise translatable messages or contextual separation. A translator should not create a private key convention inside a PO file that code does not recognise. Likewise, they should not rewrite a module’s PHP functions merely to make the translation engine distinguish two words. Code ownership remains with the developer, while the linguist explains the ambiguity and proposes meaningful alternatives.
Test both actions in staging. The modal must disappear without altering data; the ticket must enter the intended closed state, with any associated status message accurately translated. This example illustrates a subtle failure: one target can be grammatically correct and technically valid, yet wrong for one of two UI functions. Context and action testing catch a mistake that no blank-string counter can detect.
Interface language and content language need not be identical
A multilingual Drupal site may negotiate interface and content languages through different rules or contexts. An administrator might view the site interface in English while reading a French article; a visitor might choose a French path prefix but encounter an English quotation supplied by an author. Those are not necessarily defects in interface translation. Before testing, identify which language is expected for the interface in the current request. A browser’s preference alone may not override the site’s configured negotiation method.
Compare two reproducible requests or test users where only the intended interface-language dimension differs. Open the same administrative route or form and record the actual selected language. If a target string appears only when one prefix or user preference is active, the translation might be correct while navigation or negotiation is not configured as expected. If the interface still displays the source phrase under the target language, look at the string ownership and import state next.
Avoid changing all language settings at once to make a single button work. That risks unintended effects on content URLs, SEO language relationships, cache variation and user experience. This page does not attempt to design a complete multilingual routing strategy; it asks the tester to verify the language chosen for an interface request. The distinction narrows diagnosis and avoids turning a translation issue into a site-wide redesign.
Drupal configuration translation is not interface translation
Field labels, Views labels, certain site names and other configuration-provided text may belong to Configuration Translation. They can appear next to core interface words on the same page, so it is tempting to assume every visible label can be fixed by importing interface strings. If the requested text is actually configuration, use the appropriate configuration translation workflow. Editing an unrelated PO entry may produce no visible change and introduce an unintended modification elsewhere.
Consider a custom content type named “Community notice” whose field label is “Meeting date”. The field label may be defined in configuration, while a nearby “Save” button is supplied by interface code. The article title written by an editor is content. The three pieces require different translation owners even though the visitor sees them side by side. A translator who knows the source map can tell the site builder which layer needs work without personally changing the site’s data model.
If a site team wants all three translated, split the project into coherent tasks and test each against its own acceptance criteria. Do not use this guide as a reason to edit configuration or content during an interface-string run. Maintaining that boundary is essential for avoiding cannibalised documentation and for protecting live site structure. The interface workflow can be finished and verified even when other multilingual work remains scheduled separately.
Content translation is also a separate editorial job
Drupal’s Content Translation module supports translated versions of eligible content entities. A news story, a resource page, a taxonomy term or another editorial object may require a translator to preserve argument, evidence, attribution and authorship. Those requirements differ from localising a “Save changes” control. A PO import will not create a carefully edited French counterpart to a 2,000-word policy article. Nor should it change the underlying author or publication date without a content-governance decision.
The distinction is practical for school and nonprofit websites. The interface might read French while a teacher’s lesson remains English because no translated lesson has been authored. That is not fixed by editing “View” and “Read more” strings repeatedly. Assign the lesson to the content translation workflow, with subject-matter review. Keep interface changes focused on controls that help users navigate and understand actions.
This separation also protects SEO and URLs. A multilingual content strategy may involve translated slugs, page relationships and metadata, but those decisions are beyond a Locale PO-import task. An interface label can become French while its route remains technically stable. If the user explicitly needs translated page addresses, treat it as a routing and content architecture project. Do not accidentally alter route definitions while trying to make a link caption more natural.
Custom modules: translation starts with developer exposure
Drupal custom modules can generate interface text in PHP, Twig and JavaScript. Developers must expose translatable messages using the appropriate Drupal APIs and conventions for the installed release. Drupal’s translation functions support variables and context-aware handling; those are part of the message contract. If a developer prints raw English directly to a page, an interface translation import may never find an applicable resource to replace it. The translation editor cannot fix every untranslated custom string alone.
Suppose a custom module displays “There are three open requests” by constructing a sentence from separate fragments around a number. The developer should provide a language-aware message pattern suitable for grammatical variation, not ask translators to translate “There are ” and “ open requests” independently. A Japanese or Arabic target may require different order, and plural logic may need specific handling. The correct design depends on Drupal’s applicable API. The translator’s task is to explain the meaning and constraints, not to improvise replacement code inside a catalogue.
When a custom message is missing from the translation interface, record the page route, module, source code location if known, exact source wording and expected target. Ask the developer whether the message is exposed properly. If context is needed to distinguish two meanings of “Open”, document the contrast. After a code fix, import or refresh the appropriate translations and test the actual output. That is faster than creating unsupported catalogue entries and hoping the runtime will use them.
Placeholder values: preserve syntax, translate the complete sentence
Drupal translatable messages may contain replacement variables. In relevant APIs, placeholders such as @name are not ordinary words; they tell the system where to insert values and how to handle them safely. The exact forms depend on the translation function and context, so follow the versioned API documentation. A translator can change the order of surrounding words to produce a natural sentence, but should not casually rename placeholder identifiers or delete a required value.
Consider the example message “A request from @name was received.” The name could be long, include diacritics or contain non-Latin characters. A French translation might move the phrase around the name while retaining the technical placeholder. The reviewer should test with a name containing punctuation or special characters, not only the simple sample “Alice”. Rendering must not mistake user-supplied data for executable markup. The developer’s escaping and translation mechanisms have security responsibilities beyond prose style.
A placeholder audit asks which variables appear in the source, which appear in the target, what types of values they represent and whether their positions make grammatical sense. It then renders the real message. A count or syntax comparison can catch missing tokens; it cannot tell whether the target sentence assigns the action to the right actor. If the message says the visitor received a request when the system meant the visitor submitted it, the data may be inserted correctly while the grammar reverses responsibility.
Plurals: count-dependent wording is not one English suffix
A phrase such as “1 result” versus “2 results” is not always solved by translating an English singular and then adding a suffix for larger numbers. Languages have different grammatical number systems and may use several count-dependent forms. Drupal supports plural-aware translation mechanisms, and PO catalogs can represent plural variants. The source developer should supply the required pattern or message form; the translator should complete target variants appropriate to the language rather than force English rules onto all locales.
Use a real test that renders zero, one, two and a larger count when these values are meaningful. Include additional counts required by the target language’s plural categories or the relevant project specification. Inspect both wording and actual result count. A translation can be structurally correct but refer to “messages” when the screen shows search results, or imply zero results is an error when the screen simply has no matches.
Do not translate numerical output by changing application logic inside the PO file. If the runtime selects a wrong plural variant, investigate the message definition, target catalog and locale configuration together. If the correct variant appears but sounds awkward, that is a linguistic revision. The test must distinguish the two. The objective is to let the application’s formatting system handle counts while the translator supplies grammatical target messages that are meaningful for each state.
Imported strings, local overrides and maintenance responsibility
Drupal’s interface translation tools support imported and locally maintained translations. The team should know whether a phrase came from a community package, a project-provided PO file or a local admin edit. Local customisations may need protection when translation updates are fetched or a module is upgraded. Do not assume that all imported values share identical precedence or update behaviour in every environment. Verify the options provided by your Drupal release and the actual update settings before applying a broad import.
Keep a small register of overrides that matter. Record language, source phrase and context, owning module, former translation, replacement, reason and reviewer. If a community update later provides a better translation, compare it against the local choice. A brand-specific preferred term may still be needed; a temporary workaround may no longer be justified. An override that persists forever without explanation becomes an invisible fork of the site’s language system.
Use the same logic for custom module releases. A source phrase may change from “Request sent” to “Request queued”. An old target that still says “sent” might misrepresent processing state even if it remains syntactically valid. Re-extract or refresh messages, review changed entries, and test their new contexts. Translation is a maintained asset tied to software version, not a one-time decoration layered on top of code.
Caches and language negotiation explain many apparent failures
A saved translation that does not appear in the browser can have several causes. The current request may be using a different interface language; a cache may hold an earlier render; the source string might belong to a different module or configuration layer; or the PO import might have targeted the wrong locale. The most useful diagnostic step is to vary one factor at a time. Confirm language selection, string identity and import state before clearing caches as a universal cure.
Drupal pages may be cached in ways that reflect language contexts. When testing, use the supported cache-rebuild or invalidation workflows of your environment after translation changes, and confirm that language-specific output is not leaking across contexts. Do not indiscriminately disable caching in production just to test a label. A site that displays a French button to one user and an English button to another may be behaving correctly; the bug is when a cache or negotiation error ignores the intended interface language.
Compare a fresh anonymous request with an authenticated test account if the feature is public. Record the route, selected language and observed text. If the target appears in one case but not the other, investigate differences in language selection, role, page variant or caching. If neither case shows the target, confirm the source phrase and translation entry. Treat each observation as evidence. Re-importing the same file three times without changing the hypothesis wastes time and risks overwriting intentional local edits.
Right-to-left text and accessibility need real rendering checks
Some Drupal target languages use right-to-left writing direction. A correct translated label is not enough if the theme’s layout, icon order, punctuation and focus progression make the action confusing. Verify that the active theme and custom components support the intended text direction. Do not insert directionality characters into a PO file as a blanket fix for a layout problem; such changes can interact with embedded numbers, URLs and technical tokens in unpredictable ways. Use documented presentation mechanisms and test with actual content.
Even in left-to-right languages, longer target labels can crowd navigation bars, hide controls or wrap at poor points. Check common mobile widths, keyboard navigation and accessible names. A screen reader may announce visually hidden control text that the translator did not see in a screenshot. If the site uses icons without visible labels, their accessible alternatives also deserve language review. Locale work is incomplete when only sighted desktop users can understand the interface.
Do not shorten “Delete permanently” to “Delete” merely because a narrow button looks cleaner. The action’s consequence matters more than the character count. If layout breaks under a faithful translation, the theme or component should be adjusted where possible. Separate rendering defects from language defects in the issue register so the right person can fix them. Good multilingual design should not require translators to conceal the significance of an action.
Error messages reveal the value of translating with state context
A form may present several error messages: a required value is missing, an email address is invalid, permission is denied, the server is unavailable, or a submission has already been processed. These are not interchangeable inconveniences. If the target transforms all of them into “Something went wrong”, users lose the information they need to recover. A translator should see what action caused each error and what the user can do next. The developer should expose complete, context-rich messages rather than fragments.
Our fictional civic contact form has a validation error and a success message. The validation target must not imply that the message was sent. The success target must not promise a personal reply within a period the organisation has not established. A permission error must not imply that trying again will grant access if the account lacks rights. Translate each according to its true system state and the degree of certainty the source supports.
Test the messages with safe fixture data and appropriate roles. A content editor may see an administrative error that anonymous visitors never encounter; both can need translation, but the risk and audience differ. Record the route and triggering condition for every high-risk phrase. That record is reusable context for future languages and future module updates, reducing the time a reviewer spends reconstructing why one error exists.
A practical Drupal interface-string QA matrix
For a bounded release, build a matrix with four dimensions. First, interface language: source and target. Second, audience: anonymous visitor, authenticated member and site editor where relevant. Third, component: core navigation, custom form, extension screen and administrative message. Fourth, state: normal path, empty state, validation error and successful completion. Do not exhaustively cross every dimension if the application does not use it; select representative cases by risk.
For each scenario, write a one-sentence expectation. “Under French interface language, the contact form validation warns about a missing email address while preserving entered message text.” Test the actual interaction and note whether the behaviour matches. Check that a translated navigation label still points to its intended route and that a language switch does not send the visitor to an unrelated page. If a route changes because of an independent multilingual-content configuration, record that as a separate architecture issue rather than silently altering interface translation.
Screenshots help, but pair them with observations. A beautiful screenshot does not prove that a final submission button is semantically clear or that a form preserves data after an error. The tester should record both what the label says and what happened. That pattern catches user-facing contradictions early. It also gives translators an evidence-based way to resolve disputed target words without treating personal taste as the final authority.
An import and rollback routine that avoids broad surprises
Before importing a target PO file, confirm its provenance, locale, source project and intended version. Validate syntax and inspect a sample of high-risk entries. Record whether the import is meant to add missing translations, update existing ones or replace specific local entries; use the supported options in the target Drupal release. Keep a backup or export of the previous relevant state. Do not apply an unreviewed bulk import during a live enrolment or payment period merely because the file has the right extension.
Import in staging, then use the interface translation page to verify that representative entries are present. Test the rendered routes under the target interface language and evaluate both normal and error states. If a phrase does not change, investigate source ownership and language selection before repeating import. If an unrelated phrase changes unexpectedly, check the scope of the file and whether existing local translations were overwritten. Roll back the specific problematic entries or import according to the planned recovery path.
When staging passes, deploy through the site’s usual change process and repeat smoke tests on the delivered environment. A staging database may have different modules, content, cache settings and translations from production. The release record should state what was imported, which strings or project were in scope, how the language was selected and what visible outcome was confirmed. This evidence makes later support requests faster because nobody must guess which file changed the site.
Collision boundaries: this guide does not own the whole multilingual site
A multilingual Drupal project may include translated news pages, menu structures, Views configuration, media captions, SEO metadata and language-specific URLs. Each is important, but combining them into one “interface translation” article would hide the mechanism readers came to learn. This page owns code-provided interface strings and PO import review. It explains content and configuration only to help identify when the requested phrase belongs elsewhere. It does not offer an alternative set of instructions for publishing translated articles or creating hreflang strategies.
That separation is useful for internal knowledge architecture too. A person whose Drupal button remains English should land on a page explaining Locale, language choice, string source and imported values. A person whose editorial article remains English needs a content-translation guide. A person whose field label is wrong may need Configuration Translation. Routing readers to the correct job saves them from instructions that are accurate but irrelevant to their task.
If a support ticket contains several layers, split it into linked subtasks with distinct owners and acceptance tests. For example, “French contact form” may need interface messages, form configuration text and a translated privacy notice. The first can be completed and validated independently while the others progress. A single broad ticket hides dependencies and can produce the false claim that a site is entirely translated because its Submit button is French.
A fifteen-minute training drill for a site builder and translator
Choose a staging page containing a simple interface phrase such as “Back to list”. Ask the site builder to identify whether it originates from code, configuration or authored content before using translation tools. Find the relevant source entry and choose a target equivalent. Test a language switch that is known to work on the site. Save the local interface translation or import a small controlled PO file, then inspect the same route as the target audience.
Next, deliberately introduce a misunderstanding in a copy of the fixture: use “Close” where the interface performs a permanent closure rather than dismissing a panel. Ask the translator to explain the difference and the developer to identify whether source context is sufficient. Fix the phrase through the correct ownership path. Then test a placeholder-bearing message with an accented and a long synthetic name. Restore the original staging state after the exercise if the example was only for training.
Finish by comparing two failures: one target string is linguistically wrong but appears on the correct page; the other target is excellent but never displays because a configuration label was mistaken for an interface string. The remedies differ. When participants can diagnose both without guessing, they have learned the core of rapid Drupal interface translation: identify, localise, render, verify and maintain.
Transfer: why ownership matters more than the number of translated words
Drupal’s multilingual modules show that translation is not one database column. Code strings, configuration, content and user data have different lifecycles and owners. The visitor’s page blends them into one experience, but the maintainer must separate them to make safe changes. A translation can be linguistically excellent and invisible if it was entered into the wrong layer; a visible translation can be misleading if it describes the wrong action. Both are corrected by following the source-to-interface mechanism.
The transferable lesson is an audit trail. For every changed phrase, know who owns it, what makes it display, which language applies, what behaviour it describes, and how its correctness is tested. Drupal provides concrete tools for this in Locale, PO import and language negotiation. Other software stacks implement different mechanics, but the principle is the same: an interface message is part of a working system, not an isolated sentence waiting for a synonym.
For adjacent eduKateSG methods, GNU gettext PO and POT translation QA explains general catalogue integrity, placeholder handling covers protected variables, and localisation build validation covers technical release checks. This page owns the Drupal-specific task of making a translated interface string arrive on the right page, under the right language, without confusing it with content or configuration.
Frequently asked questions
What is Drupal interface translation?
It is the localisation of strings provided by Drupal core and modules for the interface, using the Locale functionality and supported translation resources. It differs from translating articles, content entities or configuration-defined labels. Start by identifying which layer owns the phrase you want to change.
How do I import a PO translation file into Drupal?
Use the supported Interface Translation import workflow for the relevant Drupal version after configuring the target language. Verify the file’s project, source version and locale, back up important local changes, import in staging, and inspect actual rendered pages. A successful import is not proof the correct string or language was selected.
Why does the page remain partly English after I install a language?
Some strings may lack available translations, come from custom code not exposed for translation, belong to content or configuration, or use a different selected interface language. Check each phrase’s ownership before assuming one missing package explains everything. A translated interface does not automatically translate editorial pages or user records.
Is Drupal Locale the same as Content Translation?
No. Locale/Interface Translation deals with code-provided interface strings. Content Translation manages eligible content entities and their language versions. Translating a news article is an editorial content task, not a PO replacement for a Save button.
When should I use Configuration Translation?
Use it for eligible configuration text such as certain field labels or Views settings. A nearby interface button may still belong to Locale, while the page body may belong to content. A source map prevents changing the wrong translation system.
Can I change a PO source msgid to make its English clearer?
Not as an ordinary target-language edit. The source message is part of the lookup relationship with code or extraction. A source-copy correction belongs with the developer or source owner, followed by regenerated translation resources and review of target entries.
What should I do with placeholders such as @name?
Keep the placeholder identities and formatting contract intact, translate surrounding language as a complete sentence, and test real rendering with representative synthetic values. Check the particular Drupal API’s placeholder rules for your version. Never insert untrusted data into markup as a translation shortcut.
Are plural forms in a PO file just singular and plural English equivalents?
No. Target languages can have different grammatical number categories and rules. Use plural-aware source messages and complete the required target variants, then test relevant counts at runtime. A correct plural catalogue still needs contextual checking against what the interface is counting.
Will an imported interface translation change my article URLs?
Not as an ordinary interface-string edit. Display labels and technical routes have different owners. Multilingual URLs and translated content slugs are part of a broader routing/content strategy and should not be altered incidentally while fixing interface messages.
How can I tell whether caching or the translation itself is wrong?
Verify the selected interface language, source string identity and imported target value. Compare reproducible requests and roles, then use the supported cache-management process if needed. If the wrong string was edited, a cache rebuild will not produce the desired meaning. Fix the cause shown by evidence.
Summary: translate the site shell through the layer that owns it
Fast Drupal interface translation begins by naming the layer. For a Locale string, identify its source and context, use a suitable existing translation or reviewed PO file, import or edit the right entry, confirm interface-language negotiation, and test real behaviour. Protect placeholders, routes and technical code. Do not confuse an untranslated article, configuration label or record with a broken interface catalog. The result is a predictable workflow: the right words reach the right user while Drupal’s underlying actions and site structure remain intact.
Official references for current Drupal implementations
The starting references are Drupal.org’s Choosing and installing multilingual modules, Translating site interfaces, Installing a language, the Drupal 11 internationalisation API overview, and the Drupal 11 interface translation PO properties. Check release-specific details, especially for custom modules, language negotiation and import overrides. The civic contact-form scenarios are instructional examples.