On Thu, Oct 25, 2012 at 11:57 AM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: > On Wed, Oct 24, 2012 at 09:07:22PM +0300, Zeeshan Ali (Khattak) wrote: >> However that would involve doing one extra string >> allocation/duplication for each untranslated node here. I really would >> want to avoid doing a lot of redundant computation/allocation for a >> something that may never happen. >> >> If the code could be written some other way that doesn't involve >> string allocations, I'm all ears. > > Just compute the substituted language list once at runtime. I already thought of that but then realized that string allocation/duplication is done to create an xpath query that combines the node in question and language so we have to do with for each node and lang combination. > But it's > probably not worth fighting with that. And probably not possible either. >> However, I recalled a few hour ago that we have the plan to setup a >> centralized database[1] and having translations in the xml itself will be >> very much desirable for that. > > After a bit more homework, GConf schemas used to do that, but it had a > measurable impact on login time since all translations had to always be > parsed even though the user only needed a few. However, if this ever came > to be an issue for us, we still have the option of doing the same as what > GConf did, ie split the XML file in one XML file per translation. Hopefully > the files will be small enough that this won't be needed ;) I hope we don't need to load libosinfo db at login time either. :) So whats the verdict, to merge or not to merge translation in XML? -- Regards, Zeeshan Ali (Khattak) FSF member#5124
