On Fri, Oct 19, 2012 at 4:53 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: > On Fri, Oct 19, 2012 at 03:38:04PM +0200, Michal Privoznik wrote: >> The biggest question is: are <name/>, <version/> and <vendor/> sort of >> ID or not? If it is so, then we cannot translate it; if they are not an >> ID, then we can translate it, wisely. > > Imo name and vendor are not ids. For 'name', there is 'short-id' which is > an id, and 'vendor' probably has some overlap with 'distro', and the latter > looks more like an ID. As said in another email, I'd tend toward not > translating the version field though. Yeah, after reading that I think I agree with you now. I'll remove version from my patch.. >> My biggest concern is to not force libosinfo consumers to change >> anything (esp. in non-easily-solvable way -> translating Windows from >> Farsi to English). But on the other hand, our consumers can set locale >> before they link with libosinfo, right? I mean: >> >> setlocale(); >> dlopen(); >> >> Which sucks really, doesn't it? > > Yep, we don't want to go that way, especially when we have multiple > threads. > >> So maybe, if libosinfo would implement a function to enable localization >> (and eventually set one)? That would leave both sides happy, right? > > This could work, but it would be better if we could avoid it ;) Yeah, I don't think we need such a global api. For fields like 'vendor', we could just have a bit of redundancy and have both translated and untranslated versions exposed to apps. -- Regards, Zeeshan Ali (Khattak) FSF member#5124
