On Mon, Sep 22, 2014 at 10:21 AM, 'Terry Brown' via leo-editor
<[email protected]> wrote:
> Maybe not adding much here, but my just guessing haven't done
> it myself impression of the most general approach to localization is
> that all in code strings are wrapped in a function call, with the
> function often being called `_` to minimize its intrusiveness. E.g
>
> g.es("No @file nodes in tree")
>
> becomes
>
> g.es(_("No @file nodes in tree"))
That should not be necessary. The convention that odd-numbered args
get translated is equivalent to wrapping odd-numbered args x in calls
to _(x). The convention allows you to mix translated and untranslated
arguments. For example:
g.es('can not open',fileName) # Translate 'can not open' but not fileName.
> Leo will be a bit more complicated because of the way it uses plain
> text as a data type. How would we distinguish non-translatable text,
> e.g.
>
> @string body-font-family = @font-family
>
> non-translatable in the sense that
>
> @string körper-sind-familie = @sind-familie
Correct. It would require significant work to translate settings.
> But I don't see any reason the _("") part couldn't be worked on - apart
> from adding the _("")
The only thing needed to translate log messages is to get the call to
gettext.gettext(s) inside g.translateString to work properly.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
