Need internationalization for strings in forms and templates

Bug #745919 reported by Connor Carney
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Scatterand
In Progress
Critical
Unassigned

Bug Description

With much of Scatterand's UI provided by HTML documents, we need to localize HTML provided by both the built-in templates and the included forms. Components that need to be localized include *at minimum*:

_( )-wrapped strings in 00-webui.js
Body text (non-whitespace text nodes) in forms and templates
_()-wrapped text in value attributes in forms and templates

It would be good to use gettext as part of this process, so that localization is consistent across components, however:
(a) it is impractical to localize documents every time we serve them; we would need to localize everything once and serve the localized copies
(b) we don't want a hard dependency on gettext, since a lot of web servers won't have it installed. If gettext isn't available, we'll fall back to non-localized english strings.

Connor Carney (cscarney)
Changed in scatterand:
importance: Undecided → Critical
Connor Carney (cscarney)
Changed in scatterand:
status: New → Fix Committed
Revision history for this message
Connor Carney (cscarney) wrote :

This is fixed. The build script now extracts translatable text from HTML files in the data/form and data/template directories. continuous, non-empty text node is converted into a translatable string. When serving forms and templates, these strings are translated, and the results cached in ~/.scatterand/translations/$(LOCALE). 00-webui.js is scraped using xgettext during the build process; the translations are substituted textually when serving the script, and the results also cached.

Revision history for this message
Connor Carney (cscarney) wrote :

Oops, just realized I don't have <meta> translating yet. Changing back to "In Progress".

Changed in scatterand:
status: Fix Committed → In Progress
Revision history for this message
Connor Carney (cscarney) wrote :

Realizing that straight <meta value> translation is not a good idea, as meta values are not necessarily human-readable (the style sniffer stores JSON in there; filenames are often stored, etc. Updating the bug description to reflect that we're going to handle _("...") in value attributes instead of *all* value attributes.

description: updated
Changed in scatterand:
milestone: none → 0.1
Connor Carney (cscarney)
Changed in scatterand:
assignee: nobody → Connor Carney (cscarney)
Revision history for this message
Connor Carney (cscarney) wrote :

It's going to end up being absurdly expensive to translate attribute values textually. It's going to take a server-side HTML parser to make this work, and that's not going to happen for 0.1. Bumping to 0.2.

Changed in scatterand:
milestone: 0.1 → 0.2
Connor Carney (cscarney)
Changed in scatterand:
milestone: 0.2 → 0.4
Connor Carney (cscarney)
Changed in scatterand:
milestone: 0.4 → none
Connor Carney (cscarney)
Changed in scatterand:
assignee: Connor Carney (cscarney) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.