On Wed, Mar 28, 2018 at 05:35:35PM +0200, Christophe de Dinechin wrote: > > On 28 Mar 2018, at 17:04, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: > > The part I'm missing is how you extract this limited number of full > > strings that we'll need to translate into a po file (or equivalent). Is > > there a tool which will generate that list of strings from %s writing > > %s for file ... and the static strings which are passed as %s arguments to > > snprintf? > > Would the answer to this question have any chance of tilting the > balance back towards changing the type of ‘message’ to std::string in > the Error class? If not, why are you even asking? You brought back multiple times the topic of localization, this made me think this was an important part of the design which we might want to discuss. I'm fine if we stop mentioning l10n in the discussion of this patch series, I probably have already suggested that in the past :) > > That being said, if you ask me if I believe that our code is presently > in an “easily translatable” state, no, it is not. If you ask me if my > patch is fixing that, it is not, and was never advertised as doing so. > However, I’d argue that it moves the cursor from “impossible to > translate” to either “tedious to translate” or “easy to translate with > poor translations”. Hmm I'll beg to disagree here, adding fairly standard gettext support to git master seems quite easy, I experimented with it when localization was mentioned a few weeks back: https://gitlab.com/teuf/spice-streaming-agent/commits/i18n As indicated by my earlier question, with your proposed Error design, I'm not so sure how we could add good translation support. Christophe
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel