[Bf-translations-dev] Some glitches with translations (or at least Spanish one)

[Bastien Montagne]

Gha, forgot to reply to that one, sorry… :/

On 09/09/2012 11:10, Sergey Sharybin wrote:
> Hi,
>
>     1) In the _left listing of channels in the Graph Editor_: none of
>     the tooltips, nor the LocRotScale string or the "<object>Action"
>     string are translated. Also the channel names (X Position, Y
>     Position, etc.) remain with the X, Y, Z letters to the left of the
>     string, while in Spanish they should be placed at the (right) end
>     of the word (i.e. X Position <=> Posición X)
>
>
> That's true and it's not so obvious to fix. Such a strings are 
> automatically generated based on property name (which is "Position") 
> and vector component name (such as X, Y and Z).
> The question here would be (mostly to others from the translation 
> team) -- is there some general way to handle such a things from 
> translation files? It'll be nice to have some general way handling 
> such a things.
Have no clue here, except I suspect this to be complex to fix nicely
… Would say it’s relatively low priority for now. ;)

>     2) The _Scale_ term is used in two different contexts, as verb and
>     as noun, each of which in Spanish are written differently:
>     - as a verb: Object Tools>"Scale" and Graph Editor>Key>Transform
>     menu>"Scale". (in Spanish it would be "Escalar")
>     - as a noun: Properties panel>Object context>"Scale:" and View
>     Properties panel>"Scale:". (in Spanish it would be "Escala")
>     in fact in the PO file there are two strings, one "Scale" and the
>     other "Scale:" but for some reason the first one seems to be the
>     only one (I saw) at use.
>
>
> Properties (like Properties panel>Object context>"Scale:) does not 
> contain colons in their names, colon is appending automatically. 
> That's why Scale is used in both cases you're mentioning. "Scale:" 
> goes from sequencer's transform effect.
> I've implemented contexts for translations a while ago. Are there some 
> issues with them or we simply need to move this words to different 
> contexts?
Nope, contexts are working, just not that much used for now. It’s a bit 
tricky to define “good” contexts, but will give it a try asap.

>     3) Shortcuts' _key names_ don't appear translated.
>
>
> Seems Event.type enum is not taking into account when translation 
> template is generating. Would need to look into updated scripts which 
> generates this template.
Will give it a try too.

>  4) The string _New_ is used in a lot of contexts, several of them 
> refer to female elements and others to male ones (in Spanish, of 
> course). In its current state, the translation is treating all of them 
> as male ones. But Texture, Image, Scenes, Masks and other elements 
> should be treated as female ones.
>
> That's the same as Scale, need to be moved to context.
Yep… Here probably one context per “following word”, as each language 
will have its own genders distributions (among other things). Not nice, 
but can’t see any other solution.

>     5) The string in Import/Export>_Motion Capture_ is not translated
>     (translated but not used by Blender)
>
>
> That's another tricky part. Importers/exporters are addons which 
> implies such an issues:
> - They could use stuff like layout.operator(text="") which wouldn't be 
> gathered by template generation script
> - They could be disabled by default, so strings from them wouldn't be 
> gathered as well
> - It should be possible to have translations for "external" addons, 
> meaning that everyone who writes an addon should be able to define 
> translations for it, so blender's "core" translation wouldn't hold all 
> the strings for all possible addons.
>
> If you hard-code "Motion Capture (.bvh)" into translation file, it 
> should work. Would check on this a bit later, probably there's some 
> bug or so. But i honestly want to find a nice way handling 
> translations for addons.
>
> Probably plan for this would be:
> - Contrib and addons not from our svn could provide own .po files, 
> which would be "merged" with main translation files. Not sure if it's 
> easy to do. Any other ideas of doing such a thing?
> - Think official addons could be handled in general way (meaning all 
> strings from them would go to main translation template)? Its official 
> addons anyway, why should we discriminate them? :) To do this, we'll 
> need to tweak template generation script to enable all official addons 
> on startup and add addons directory to pytext strings gathering.
Right now, official scripts are already translated (at least, they 
should be, never did a full check on that!). Agree community addons 
(i.e. the other addons released with Blender) could use custom po’s that 
would be merged at “i18n compile” time, but I can’t see how to do with 
other addons, except work into py API to emulate translation process 
(perhaps something similar to context overriding of operators call?). 
Nothing simple I fear.

>     6) The string _Active Keying Set used to insert/delete keyframes_
>     don't seem to be in the po file.
>
>
> Not actually sure what does it mean. Is it about default name for 
> Keying Set is not translatable? Otherwise i'm not so familiar with 
> animation part..
This one (as well as a bunch of others) is part of a Collection-related 
class (kind of list, if you prefer), and are currently ignored in the 
i18n strings extraction process, with the following comment:

         # [Ignore] classes which are attached to collections, these are api
         # access only.

Not sure whether we really need those?

Kind regards,
Bastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-translations-dev/attachments/20120909/b39a9db9/attachment.htm