Question

I’m developing a multilingual PHP web application, and I’ve got long(-ish) texts that I need to translate with gettext. These are email templates (usually short, but still several lines) and parts of view templates (longer descriptive blocks of text). These texts would include some simple HTML (things like bold/italic for emphasis, probably a link here or there). The templates are PHP scripts whose output is captured.

The problem is that gettext seems very clumsy for handling longer texts. Longer texts would generally have more changes over time than short texts — I can either change the msgid and make sure to update it in all translations (could be lots of work and very error-prone when the msgid is long), or I can keep the msgid unchanged and modify only the translations (which would leave misleading outdated texts in the templates). Also, I’ve seen advice against including HTML in gettext strings, but avoiding it would break a single natural piece of text into lots of chunks, which will be an even bigger nightmare to translate and reassemble, and I’ve also seen advice against unnecessary splitting of gettext strings into separate msgids.

The other approach I see is to ignore gettext altogether for these longer texts, and to separate those blocks in external subtemplates for each locale, and just include the one for the current locale. The disadvantage is that I’m separating the translation effort between gettext .po files and separate templates located in a completely different location.

Since this application will be used as a starting point for other applications in the future, I’m trying to come up with the best approach for the long term. I need some advice for best practices in such scenarios. How have you implemented similar cases? What turned out to work and what turned out a bad idea?

Answer 1

Here’s the workflow I used, on a very heavily-trafficked site that had about several dozen long-ish blocks of styled textual content, translated into six languages:

1. Pick a text-based markup language (we used Markdown)
2. For long strings, use fixed message IDs like “About_page_intro_markdown” that:
   • describes the intent of the text
   • makes clear that it will be interpreted in markdown format
3. Have our app render “*_markdown” strings appropriately, making sure to allow only a few safe HTML tags
4. Build a tool for translators that:
   • shows them their Markdown rendered in realtime (sort of like the Markdown dingus)
   • makes it easy for them to see the now-authoritative base language translation of the text (since that’s no longer in the msgid)
5. Teach translators how to use the new workflow

Pros of this workflow:

• Message IDs don’t change all the time
• Because translators are editing in a safe higher-level syntax, hard to mess up HTML
• Non-technical translators found it very easy to write in Markdown, vs. HTML

Cons of this workflow:

• Having static unchanging message IDs means changes in the text need to be transmitted out of band (which we’d do anyway, as long text can raise questions about tone or emphasis)

I’m very happy with the way this workflow operated for our website, and would absolutely recommend it, and use it again. It took a couple of days to get started, but it was easy to build, train, and launch.

Hope this helps, and good luck with your project.