[Bf-committers] [Bf-translations-dev] About translations (i18n) contexts

Bastien Montagne montagne29 at wanadoo.fr
Tue Feb 17 11:04:59 CET 2015

Yeah… main translation work in PY/RNA was reviewed, but not 'details' 
like adding the context thing to ui api it seems
(at least from commit log, 

But I absolutely think a per-button context override is the best 
solution by far, because:
* We only need that in few cases (a few percent of our UI messages), so 
using it for all
   UI messages of a panel would be really stupid (and would make our 
po's size uselessly grow).
* A single context for a whole panel would most likely not work in all 
cases even.

Being able to switch context while defining the UI would do pretty much 
the same thing
as we already do, but be more verbose, need to store that context 
somewhere, …

Note operator's default context is **only** used for operator's label 
(not its properties,
not even his tip, because tips never need a context in practice).

Anyway, will try to be on IRC this afternoon and night - and we also 
already have a task on phab
about it, https://developer.blender.org/T43295.

Le 17/02/2015 02:28, Campbell Barton a écrit :
> Bastien, something I'm not so pleased with is (AFAIK), there was never
> a discussion on how best to handle translation context in our Py/RNA
> API.
> Since you do a lot of this work without much help, I understand its
> not practical to discuss *every* detail.
> But this touches enough UI code that its good to check with others.
> Why not (for example) handle this the same way we do for
> `UILayout.operator_context`?
> Then we can set the context once at the top of a panel/menu, probably
> in most cases contest switching isn't needed within the one layout.
> And in the few cases it is, its no big deal.
> Probably better this kind of design discussion happens on Phrabricator, though
> On Mon, Feb 16, 2015 at 10:11 PM, Bastien Montagne
> <montagne29 at wanadoo.fr> wrote:
>> Gettext contexts are already used in several areas, since work done up
>> till the freeze
>> two years ago was never removed from the code. For example, all
>> operators' labels
>> use by default (and automatically) the 'Operator' context. Same for some
>> generic
>> ID-related things.
>> If you want to see an explicit usage of contexts (i.e. needed when doing
>> 'manual' disambiguation):
>> * C UI code: We use macros defined in BLF_translations.h, like here:
>> https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/armature/armature_relations.c;9daac198f5610b7e7bb5354789082b97a8e11b36$812
>> * Python: We use optional parameters, like here:
>> https://developer.blender.org/diffusion/B/browse/master/release/scripts/startup/bl_ui/space_userpref.py;9daac198f5610b7e7bb5354789082b97a8e11b36$524
>> Once again, we usually *do not need* to do anything, especially since a
>> few automatic behaviors
>> (like specific context for operators) already solve most of issues.
>> Manual context handling only remains
>> needed in a few cases (maybe a one or two hundreds of labels at worse,
>> among over 21000 translated messages).
>> Quite obviously, it’s usually very short ones (single word…) that are at
>> stake here.
>> PS: should probably have included that page in first mail:
>> http://wiki.blender.org/index.php/Dev:Source/Interface/Internationalization
>> Le 16/02/2015 11:12, Campbell Barton a écrit :
>>> For me (and probably other devs not so familiar with translations),
>>> this is a bit too abstract.
>>> Is there a patch or examples which gives us a good idea what our
>>> C/Python UI code will look like once gettext contexts are being used?
>>> On Mon, Feb 16, 2015 at 8:37 PM, - LEON - <leon4you at gmail.com> wrote:
>>>> Hi all,
>>>> During the past years, I've reported so many bugs, thanks to all passionate
>>>> devs, most of them are finally resolved. But when we talked about **i18n
>>>> bugs**, it always was so awkward for some reason, for years... Last time
>>>> when we mentioned "i18n project maintanance is on hold", it was really a
>>>> shock to me, because definitely it was born for a very good reason at the
>>>> beginning. I know devs got different standpoints on this issue. I can well
>>>> understand that, just want to share my opinion here:
>>>> Language diversity is something about culture, and we cannot force one to
>>>> totally understand or accept another, and definitely we shouldn't, vise
>>>> versa. But I believe we could at least try to respect that fact, and
>>>> realize that English is NOT the one that is spoken by the largest
>>>> population around the world. True, it is the most popular one, but not the
>>>> only popular one I should say. And, there are countless people out there,
>>>> students, designers, artists, FOSS fans, who really want to get involved
>>>> with Blender (they really should :-)), but a sad thing is, to do that, they
>>>> will have to learn a second language (English) first! In that case,
>>>> learning curve becomes horrible. Or, they don't have to, just with the help
>>>> of a **USEABLE** UI translation. Yeah, the word "useable" should really be
>>>> stressed, because for them it is either useable or useless. To be truely
>>>> honest, things now are getting worse, and there's nothing that all
>>>> passionate translators can do to help their compatriots further, to help
>>>> propagating Blender further.
>>>> As one of the active translation contributors, IMHO, I believe no one
>>>> touched i18n more than Bastien. So, if he says there is a valid way to fix
>>>> the horrible ambiguity/polyseme issue (yeah, horrible, because now it
>>>> causes the UI translation silly enough), I'll totally vote for that idea. I
>>>> have one faith: If i18n project gets better, then there will be chances for
>>>> more people to get involved, in their appropriate ways, peer to peer for
>>>> sure. Finally, vast contributions and donations will go towards Blender
>>>> Foundation! It is a typical virtuous cycle, a win-win thing benefiting
>>>> everyone, isn't it?
>>>> An indefinite on-hold doesn't actually help anything to anyone here. As I
>>>> said, UI translation plays such an important role to Blender that it is
>>>> either useable or useless. Please, make it useable.  :)
>>>> Blenderheads, translators and devs, two years have passed, it's time to
>>>> face it, share your thoughts on this point.
>>>> On Sun, Feb 15, 2015 at 7:27 PM, Bastien Montagne <montagne29 at wanadoo.fr>
>>>> wrote:
>>>>> Hey,
>>>>> So, almost two years ago, the 'disambiguation' process of our i18n
>>>>> messages was freezed
>>>>> (see
>>>>> http://lists.blender.org/pipermail/bf-translations-dev/2013-March/000424.html
>>>>> for details).
>>>>> Since then, people who are translating Blender have been quite
>>>>> frustrated, because you sometimes
>>>>> cannot make a valid translation (polysemy, a same english word meaning
>>>>> different things depending
>>>>> on contexts).
>>>>> We do have a valid way to fix that, called gettext contexts. It’s not
>>>>> ideal, it’s not perfect, but:
>>>>> * it is simple
>>>>> * it works
>>>>> * it does not need to redesign our whole UI message system!
>>>>> One month ago, a TODO task (https://developer.blender.org/T43295) was
>>>>> created on this subject,
>>>>> with not much attention from people from UI team so far, so I’m inclined
>>>>> to just resume adding
>>>>> needed contexts in code. We cannot wait years for someone to redesign
>>>>> from scratch our
>>>>> UI messages system.
>>>>> Cheers,
>>>>> Bastien
>>>>> _______________________________________________
>>>>> Remember to *NEVER* commit to our svn's /trunk, but *ALWAYS* to relevant
>>>>> language po file under /branches!
>>>>> Found a missing msgid? Edit this doc: http://goo.gl/XcWcr
>>>>> Have some disambiguation issue (i.e. same english word that should be
>>>>> translated in more than one way, depending on the context)? Edit this doc:
>>>>> http://goo.gl/VzppJ
>>>>> _______________________________________________
>>>>> Bf-translations-dev mailing list
>>>>> Bf-translations-dev at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-translations-dev
>>>> --
>>>> Leon Cheung
>>>> a.k.a. Zhang Yu | 老猫
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list