[virt-tools-list] [libosinfo 3/5] Mark obvious strings in DB for translation

[Zeeshan Ali (Khattak)]

On Fri, Oct 19, 2012 at 4:53 PM, Christophe Fergeau <cfergeau at redhat.com> 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