[tenfingers]

There's not much difference. In fact, you cannot expect translators to know how the underlying object is handled or write data extractor out of the file object.

If translators are cooperating with you, it's very easy to provide the needed elements directly in the format's dictionary (that is: you extract the translatable pieces for them). It also means you don't have to worry that they're going to fiddle with mutable state.

I generally write everything in english, and do back-translation to my own locale (I also cooperate for translating external projects into my locale), so I eat my own dogfood here.

I know I do not want to deal with extra lower-level subtleties here. Translation is hard already by itself. It's impressive how a good translation of a simple UI can take so much time. If I had to inspect the object to know what I can get out of it I would get crazy.

I'd take a pre-baked dictionary any time.

I've also already used the string-catalog approach in the past (heh, XUL), and I'd personally take gettext any day.

[cbsmith]

But do you see how that extra level of indirection basically maks arguments about the different formatting styles for localization kind of irrelevant?

[tenfingers]

I do, yes. But the translator needs to be aware of the extra indirection to produce the text he needs, and between a custom layer and a standard formatting syntax, the second is definitely friendlier for anyone approaching translation, even when technically less powerful.

At some point the translator will have to format some string himself.