Translate a Drupal site into Spanish

What a Drupal .po file holds, and what it does not

Drupal handles interface translation through the Interface Translation module: strings from core, modules, your theme and your own custom code are imported and exported as gettext .po files. Each entry pairs a source string (msgid) with its translation (msgstr).

For Spanish, much of core and many contributed modules already have a community translation. What usually remains is your custom modules, your theme strings and text added by your team: "Request a quote", "Your basket is empty", a form validation message. Updating the community translations first, then exporting only missing or customised strings, means you only pay for what genuinely needs translating.

What is not in the .po file: node content (pages, articles), custom blocks, taxonomy terms and most configuration entered through the admin interface. Those belong to the Content Translation and Configuration Translation modules and never pass through this file. Manuce handles the .po file; if your Spanish site is mostly editorial content, plan that work separately.

Placeholders, gender and plurals in Spanish

Drupal strings carry placeholders that must survive untouched: @name (escaped text), %title (emphasised text) and :url (a URL inside an attribute). Spanish word order often moves them: %title has been updated. becomes Se ha actualizado %title. The placeholder changes position but must stay identical, character for character.

The trap specific to Spanish is grammatical gender. The @type %title has been created. translates as "El @type %title se ha creado", but if @type is "página", the article should be "La". A wording without an article, such as Se ha creado %title (@type)., avoids the issue. These cases show up when you see the filled-in string on the live site, not in the file.

For plurals, Drupal uses msgid_plural with msgstr[0] and msgstr[1]. The usual Spanish header is Plural-Forms: nplurals=2; plural=(n != 1);. CLDR adds a "many" category for millions ("1 millón de visitas"), which this formula does not distinguish; on a website it only affects unusually large counters. Watch agreement too: @count new comments becomes @count comentarios nuevos, with the adjective after the noun and agreeing with it.

Questions and exclamations open with ¿ or ¡: "¿Ha olvidado su contraseña?". Spanish runs longer than English, so check narrow buttons and menus in your theme.

Spain or Latin America, tú or usted

Drupal ships the es language and lets you add a custom language for a regional variant, for instance es-mx. The choice matters for vocabulary: "ordenador" in Spain, "computadora" in Mexico; "móvil" versus "celular". A site aimed at both audiences is better served by neutral wording wherever it exists.

Register is the other decision to make before translating:

• usted: "Introduzca su correo electrónico", more formal, common for public services, banking and B2B;
• tú: "Introduce tu correo electrónico", frequent in e-commerce and consumer services;
• in the plural, Spain uses "vosotros" ("vuestra cuenta") where Latin America says "ustedes" ("su cuenta").

Mixing registers on the same page, a button in tú and an error message in usted, is the most visible flaw in a Spanish interface. Check the register in the free sample before running the whole file, and have the most exposed strings reviewed: login, registration, basket and contact form.

Exactly what Manuce returns

You receive the same .po file, ready to import: indentation, entry order, quotation marks, comments (including #: references), line endings, encoding and BOM are preserved. Only the values change, with ñ, á, ¿ and ¡ written as plain characters.

Each translated value is compared with its source: if @count, %title, :url or a tag is missing or altered, the translation is redone; if the mismatch persists, the source value is kept and the report says so. A string left in the source language is better than a broken message in production.

Not translated: keys, empty values, URLs, email addresses, numbers, colours, date formats, identifiers and anything marked as non-translatable. The price is based on the words in the values, excluding keys and tags.

What Manuce does not do: it does not import the file into your Drupal site, it does not translate nodes or configuration outside the .po file, and it does not produce sworn or certified translations. If your Spanish terms and conditions or legal notices must be certified by a sworn translator, that needs a different route. For a public-facing interface, the Professional level gives text ready to publish.

Preparing the export and checking after import

Before exporting:

• add Spanish (or your regional variant) to the site and pull in the available community translations;
• export the .po file for that language, keeping only strings that are untranslated or customised;
• make sure the header contains a Plural-Forms line for Spanish.

When the file comes back, read the report: strings kept in the source language because of a placeholder issue need fixing by hand. Then import the file, clear the caches and go through:

1. login, registration and contact forms, including their error messages;
2. Views listings and their pager ("Página siguiente");
3. plural messages, tested with one item and then several;
4. dates: Spanish month names are lower case ("1 de marzo de 2025"); the format itself is set in Drupal, not in the .po file;
5. numbers: decimal comma in Spain, decimal point in Mexico, to be handled in your theme or modules.

In practice

1. Add Spanish to your Drupal site and export the interface .po file for that language.
2. Upload the file to Manuce: the quote appears at once, and a free sample lets you check the register.
3. Choose the level, pay, then download the translated .po file and its report from your account.
4. Import the file into Drupal, clear the caches and check forms, plurals and any strings flagged in the report.