Second thoughts on dynamic content

Wil Clouser

2 responses

I was looking at one of the AMO v3.2 mockups today. There are strings like “See All Interface Tweaks Add-ons” that we’ve avoided up till now, but this isn’t the first time they’ve been proposed. The problem we’re having is that a string like that is from two different sources – static and dynamic data. “Interface Tweaks” is the name of one of our categories so it’s stored in the database, and the rest of the string is static, so it’s in a .po. The static string would look something like:

See All %s Add-ons

and the dynamic string would look like:

Interface Tweaks

In English, these combine and all is well, but if the second value affects the structure of the first in a dynamic way, we can’t support the phrase on AMO.

When I wrote the original code, I think I had two things in mind:

  • Categories would be changing more often
  • Localizers wouldn’t have direct access to SVN

Categories have changed a bit in the past (and they’re in mid change right now, actually), but other than the convenience of a near-instant change on the site, it doesn’t seem that beneficial to change them via the web. The second point is a big one though – by giving localizers direct access to SVN, they can update strings whenever they need to without our meddling and getting in the way. That’s a big time saver for everyone.

So, now I’m reconsidering the separation of some of the interface translations (add-on types, applications, and categories) from the rest of the static content. Looking at where we currently stand, it seems like it’s more of a hassle to describe the separation and what it does than it would be to just drop everything in the .po file. Plus we’d get the benefit of strings like “See All Interface Tweaks Add-ons.”

Categories: AMO

2 responses

  1. Ville wrote on :

    Uh. Is this final? And did I understand you correctly that you’re going to introduce more compound strings in AMO’s strings?

    Compound strings / dynamic strings suck, because they cause havoc (i.e. ugly hacks) with languages that require inflecting nouns etc. to the correct declension.

    Using dynamic strings would be ok if the dynamic (%s) part is only used in a single sense and *not* reused, and when the strings are also clearly marked as being the dynamic part in some specific (again, single) structure. I understand this could seem excessive for most (all?) romance language locales, but I believe the rest of us would benefit.

  2. Wil Clouser wrote on :

    Hey Ville,

    We’re not going to introduce more compound strings with the redesign.

    I’m saying the designers want to have that button say a certain thing and with our current dynamic/static code we can’t have that. I’m reconsidering what we call “dynamic” since it essentially doesn’t change (and, therefore, isn’t really dynamic). The proposal above would introduce new (and separate) static strings for each place the category name is used.

    This probably won’t happen in time for the redesign so I expect we’ll change the button label to something non-specific like “See All Add-ons” (to the chagrin of the designers, I’m sure).