[Libreoffice] Gettext patch

[Bjoern Michaelsen]

On Tue, 21 Jun 2011 17:39:50 +0100
Michael Meeks <michael.meeks at novell.com>
wrote:

> 	textdomain sets some sort of global variable (last I looked)
> which subsequent gettext calls then work from. That shouldn't work
> well in LibreOffice's case where we need to multiplex lots of
> catalogs at speed; I strongly recommend dgettext :-)

Right. It also is on the safe side if any threading issues(*) come up
(they always do somewhere and global state is evil anyway). Also
looking at the glib source it seems that all those calls end up in one
function with all params anyway.
  
> > Oh, yes, let's discuss this now because it affects design. I think
> > Bjoern was thinking about Linux only so they could release
> > translation updates for LibreOffice in Ubuntu without rebuilding
> > the source.
> 
> 	Which makes lots of sense for translators.

Right.

> > I thought it was a multi platform feature because all platforms
> > could benefit from separation of localization and building.
> 
> 	Well - we still need to build the english resource files, and
> then load and lookup the strings (as english) and then do the
> gettext-iness on them, so this is going to be rather slow I suspect.
> The .po files are also rather bigger than the .res files I think -
> since they need both english and translated strings in them. So this
> is not clear to me; lets discuss it at the next TSC meeting.

Well, Andras posted some different observations on the wiki, which are
interesting. Also note the other ideas there, like using the RES_ID as
context in gettext (we might need that in the beginning anyway) -- in
which case we might even drop:

a) the english string in the key
b) the english strings in the res-files (once english uses gettext too)

However, if we do that little is gained for translators (toolingwise)
if I get that right.

> > Yes, this way we can add a language to an existing installation.

Yes, that was what I had in mind. However, in that case there are also
changes needed for the icon/theming stuff as we are currently encoding
localized icon paths in the res-file, dont we? At least we are giving
out paths depending on the language in rsc calls in the build, so there
is definitively more than just strings that is localized in res-files.

> 	But you forget how evil cut+paste coding is; it is the moral
> equivalent of eating your children ;-)

Indeed.

Anyway: Cool to see this happening, Andras!

Best,

Bjoern


(*) I also wonder, if the thread local text encoding setting in osl will
bite us in some cornercase. But I guess, we will see that.

-- 
https://launchpad.net/~bjoern-michaelsen