Glom across borders

Boring technical bit

It’s been a hard week. I’ve been doing some major (more repetitive than conceptual) refactoring of the Glom source code, to make it use smartpointers for lots of the information, instead of copying by values lots. Copying by value gave me stability when I wasn’t sure how things should work, but now I’m more sure about where things should be explicitly created, shared, or copied. The memory management feels a bit like Java, but at least I still have the const keyword, and at least I still have strong compile-time typing. I’d be lost without them.

Exciting new feature

The point of this was to support translations of everything in Glom that can have a human-visible title instead of just an identifying name, such as tables, fields, reports, layout parts, relationships, etc. Rather than have little translation buttons next to each title, I chose to pull it all into one list. And if you develop a system in French but then later have to deploy it in Germany, that should be OK too. You can even test it without changing your locale, though you’d have, for instance, German field titles with Spanish menus and buttons.

Glom Translations Window

It would be very easy for someone to implement Import and Export to/from regular gettext .po files. Maybe I can even check them into cvs so that the wonderful GNOME translation teams translate the example Glom system for me.

I had considered this a post-1.0 feature, in Glom’s list of planned features, but I realise that I need this for clients in Germany, so I can still use English as my first development language when creating Glom solutions. As usual, don’t forget that your company may fund me to implement the remaining features.

Unfortunately, it only uses the first part of locale names at the moment, such as “de” for “de_DE.UTF-8”, so, for instance, you must use the same German translation for Germany, Austria, and Switzerland. That’s because I can’t find any list of real locales (whose names should also be translated themselves). iso-files seems to have only language names instead of locales.

7 thoughts on “Glom across borders

  1. For locales in GNU libc, check contents of /usr/share/i18n/locales/ on your own system (or look at the contents of different localedata packages, such as libc-localedata, belocs-localedata [on alioth], etc).

    To localise these locale names, see how Christian did it in Epiphany (constructing a name using iso-codes: iso_639 for languages, iso_3166 for countries).

  2. Oh please!

    Now, I don’t want to sound like a smartass. However, there’s one very annoying mistake many Germans make: they put blanks where no blanks belong! Don’t take this personal but this bugs not only me, but virtually everybody I know. I hereby gladly offer to help with the translation of whatever software this is for, since I can’t stand this kind of “language bug” while I could fix it. We’re open source, after all… ;)

    I don’t understand this. Even Babelfish and Google translate “Total Price” to “Gesamtpreis” and _not_ “Gesamt Preis” (brrrrrrrrrrr…).

    Sorry if this reads insulting! ;) Murray, I’m supposed to put my email address here so I suppose you have it now. I’m serious, I’ll be glad to help out!

    -Dave

  3. This is great news Murray!
    IIRC, when I last touched cell text renderers they had problems with correctly line-breaking text, which is an issue for very long strings, or strings where you explicitly want to have line-breaks (‘\n’ characters).
    Did you resolve or improve that situation somehow?

  4. Christian, no, but there’s no text yet in Glom documents yet that would need a line-break. But it could be necessary in future, so I’ll have to think about it.

Leave a Reply to Christian Neumair Cancel reply

Your email address will not be published. Required fields are marked *