I'm the Spanish translator for Blender, since 2011.
I support this request.

I've been reporting these kind of issues since years ago, still with no solution at sight in 2015.
Translation quality perception is greatly reduced because of things that could be (in most cases) easily solved with a little care.

Please allow for these kind of changes to be done.
Thanks.

this situation also confuse us from china traslaters. I was point out this question in second paragraph in this letter: http://lists.blender.org/pipermail/bf-committers/2014-December/044676.html
maybe Blender need a better gettext solution, make the string with the path ,then translater will know how to do with these same english words.

Totally agree here! Either we keep the translation maintenanced or we drop it completely.
From @Bastien Montagne (mont29)'s mail:

I would rather see its ownership taken back by ui owner

+1

I wasn't involved with translation till now, but for me it looks like things are quite messy due to the maintenance freeze. So bringing back the ownership to the UI module owner might be a good solution.

Further, I'm available to work on the german translation if needed.

Another thing is that add-ons are also translated after enabling i18n feature, however, quite a few translations can hardly make sense there, even confuse people often due to the same issue - polyseme, and it seems hardly be well fixed in the same way.

All in all, comparing to the "endless fix", I would highly vote for a better solution, a once-for-all solution, to let people all over the world love Blender more. (We have to admit that there still is a very large population knowing little about Enligh)

And, more important, to liberate Bastien! :)

Your proposal is a per-label translation instead the current per-word? I think that this require a deep work on code...

On the other side, I don't understand very well what is "bringing back the ownership to the UI module owner" proposed by Bastien and Julian... How/when this can be done?

@blend-it (blend-it) Assuming you were talking to me - I don't thinik that is my proposal. :) What I'm proposing is a brainstorm. Actually, there were ideas out there.

no news about this? :-(

@blend-it (blend-it) Assuming you mean something like this. I suggest you subscribe some mailing lists such as bf-translations-dev to keep yourself updated.

If you did, just skip. :)

Oh, yes, thanks :)

both here and on mailing lists no news about this theme, after this thread on ML... :-(

after this rB598c2dffe92f5a5deea5d2da97c405f93f7941a4 AFAIK:

• light = it's related to weight or compression (opposite of heavy)
• lamp or lightS = related to illumination

a little step on the way of a better UI translation :)

Anybody workig on the Hebrew? Can I have the MO files somewhere?

@Jeison Yehuda Amihud (JeisonAmihud) No, Hebrew translation is inactive since ages… MO (and PO) files can be found on our repository.

"Screen" and "Frame" synonyms are currently most important problems in italian translation.

One problem is Blender is BIG software, some times I not certain about where in Blender or what context is using a message. Screen image or video would help but no way exist for link that with .po files.

Sometimes context comment not help Example here:
#. :src: bpy.types.Sequence.type:'ADD'
msgctxt "Sequence"
msgid "Add"

First guess, I think this means add new sequence, but this is add one sequence with other sequence, math operator. Use context comment like this:
msgctxt "Sequence, math operator"

@blend-it (blend-it) I need specific examples (both in PO and UI, with meaning of the different translations for same English word) to handle it correctly. ;)

@Chau (BlenderNavi) Don’t think we need more detail in context here, context is primarily for gettext disambiguation, helping translators is only a secondary goal for them. Also, the :src: comment tells you more than what you may think: since it’s bpy.types, you know that this is data, not action (which would be an operator, bpy.ops..... Further more, the final formating (bpy.types.class.prop_name:'VALUE') tells you that you are dealing with a specific option/value of an Enum property here (the type of a Sequence, i.e. strip).

Indeed, you need to understand a bit of Blender’s internals (at least on its py API level) to sort some cases (or just use the try-and-fix approach), but we really cannot add more complexity to our i18n handling code-wise just to make translators’ life easier, code has to remain reasonably simple and efficient here. ;)

@Bastien Montagne (mont29): Ok, "Screen" and "Frame" disambiguation needs follow (hope this is a good way to submit, if not, please said what is better :) )

SCREEN

#. :src: bpy.types.ColorMapping.blend_type:'SCREEN'
#. :src: bpy.types.DriverTarget.id_type:'SCREEN'
#. :src: bpy.types.GPencilStroke.draw_mode:'SCREEN'
#. :src: bpy.types.Action.id_root:'SCREEN'
#. :src: bpy.types.Brush.blend:'SCREEN'
#. :src: bpy.types.Material.diffuse_ramp_blend:'SCREEN'
#. :src: bpy.types.Material.specular_ramp_blend:'SCREEN'
#. :src: bpy.types.KeyingSetPath.id_type:'SCREEN'
#. :src: bpy.types.LampSkySettings.sky_blend_type:'SCREEN'
#. :src: bpy.types.LineStyleColorModifier_AlongStroke.blend:'SCREEN'
#. :src: bpy.types.LineStyleColorModifier_CreaseAngle.blend:'SCREEN'
#. :src: bpy.types.LineStyleColorModifier_Curvature_3D.blend:'SCREEN'
#. :src: bpy.types.LineStyleColorModifier_DistanceFromCamera.blend:'SCREEN'
#. :src: bpy.types.LineStyleColorModifier_DistanceFromObject.blend:'SCREEN'
#. :src: bpy.types.LineStyleColorModifier_Material.blend:'SCREEN'
#. :src: bpy.types.LineStyleColorModifier_Noise.blend:'SCREEN'
#. :src: bpy.types.LineStyleColorModifier_Tangent.blend:'SCREEN'
#. :src: bpy.types.CompositorNodeMixRGB.blend_type:'SCREEN'
#. :src: bpy.types.ShaderNodeMixRGB.blend_type:'SCREEN'
#. :src: bpy.types.ShaderNodeOutputLineStyle.blend_type:'SCREEN'
#. :src: bpy.types.TextureNodeMixRGB.blend_type:'SCREEN'
#. :src: bpy.types.OUTLINER_OT_id_remap.id_type:'SCREEN'
#. :src: bpy.types.TextureSlot.blend_type:'SCREEN'
msgid "Screen"

In IT it's different when related to images/layers "blend type" or related to display/windows/device (as in Outliner or gpencil stroke etc).
Note that, also after disambiguation, wrong translation of this term in various context and languages is very common. Even Italian Gimp and Gimp-manual is wrong (and AFAIK also FR and ES). See https://helpx.adobe.com/en/photoshop/using/blending-modes.html and compare description/translation of the help for your languages... I think Adobe Photoshop is a good reference for colour blending modes.
So before translate "blend-screen" in Blender, check very well the better solution. I'll use the Adobe translation for Italian (and asked Gimp team for same fix).

FRAME

#. :src: bpy.types.FModifierEnvelopeControlPoint.frame
#. :src: bpy.types.CacheFile.frame
#. :src: bpy.types.ParticleSettings.billboard_animation:'FRAME'
#. :src: bpy.types.DOPESHEET_MT_gpencil_frame
#. :src: bpy.types.SEQUENCER_MT_frame
#. :src: bpy.types.TIME_MT_frame
#. :src: bpy.types.MeshCacheModifier.time_mode:'FRAME'
#. :src: bpy.types.MovieReconstructedCamera.frame
#. :src: bpy.types.MovieTrackingMarker.frame
#. :src: bpy.types.MovieTrackingPlaneMarker.frame
#. :src: bpy.types.CompositorNodeTrackPos.frame_relative
#. :src: bpy.types.NodeFrame
#. :src: bpy.types.ANIM_OT_change_frame.frame
#. :src: bpy.types.CLIP_OT_change_frame.frame
#. :src: bpy.types.GPENCIL_OT_delete.type:'FRAME'
#. :src: bpy.types.GRAPH_OT_cursor_set.frame
#. :src: bpy.types.IMAGE_OT_change_frame.frame
#. :src: bpy.types.POSELIB_OT_pose_add.frame
#. :src: bpy.types.SEQUENCER_OT_cut.frame
#. :src: bpy.types.SEQUENCER_OT_snap.frame
#. :src: bpy.types.ShapeKey.frame
#. :src: bpy.types.TimelineMarker.frame
#. :src: scripts/startup/bl_ui/properties_render.py:363
msgid "Frame"

Also, it's different for "border/envelope" (e.g. bpy.types.NodeFrame) and for a part of a video. I'm not skilled about Gpencil, but perhaps it's more on the side of "border" than "video part". For other cases, I don't know enough.
That's all for now :)

Regarding screen, I find it a bit funny to use that word and english, and then use 'superposition' in french or whatever… It’s not even correct, actually (maybe “projection” would be better, but doubt there is a perfect wording for that). So will keep “écran” in french as well, also have the plus side of being direct translation of english, and being also used in Gimp & co, reduces confusion imho…

Anyway, I see the point, in both cases, we indeed have two completely different meanings here, will see how to disambiguate it.

PS: for grease pencil, 'frame' is in line with the concept of animation frame (keyframe even), not with the border/envelope one.

Another ambiguous word is "Both". Currently in Russian translation it translated as "Везде" (which means "everywhere" in English), which is totally wrong in some cases. For example, case :src: bpy.types.CyclesMaterialSettings.displacement_method:'BOTH' would be translated as "Оба" (which means "one and another" in English). In this case, it is preferable, of course, to change the names in the interface to something like "True displacement", "Bump mapping" and "True displacement + Bump mapping", but in others - it will be "Оба" / "Обе" (note for different - masculine vs feminine).

#. :src: bpy.types.FluidFluidSettings.volume_initialization:'BOTH'
#. :src: bpy.types.InflowFluidSettings.volume_initialization:'BOTH'
#. :src: bpy.types.ObstacleFluidSettings.volume_initialization:'BOTH'
#. :src: bpy.types.OutflowFluidSettings.volume_initialization:'BOTH'
#. :src: bpy.types.SEQUENCER_OT_cut.side:'BOTH'
#. :src: bpy.types.SEQUENCER_OT_select_active_side.side:'BOTH'
#. :src: bpy.types.SEQUENCER_OT_select_handles.side:'BOTH'
#. :src: bpy.types.CyclesMaterialSettings.displacement_method:'BOTH'
#: source/blender/editors/interface/interface_templates.c:1405
msgid "Both"
msgstr "Везде"

Another word - "Tangent", which translated to Russian as "Тангенс" and implies mathematical function tan (:src: bpy.types.FModifierFunctionGenerator.function_type:'TAN'). But in most other cases, like :src: bpy.types.BakeSettings.normal_space:'TANGENT', :src: bpy.types.LineStyleAlphaModifier_AlongStroke.type:'TANGENT' and others it is meant "kind of space" and should be translated as "Касательное" or "Касательные" (this is two different meanings in Russian!)

#. :src: bpy.types.BakeSettings.normal_space:'TANGENT'
#. :src: bpy.types.FModifierFunctionGenerator.function_type:'TAN'
#. :src: bpy.types.Curve.twist_mode:'TANGENT'
#. :src: bpy.types.ParticleSettings.tangent_factor
#. :src: bpy.types.LineStyleAlphaModifier_AlongStroke.type:'TANGENT'
#. :src: bpy.types.LineStyleAlphaModifier_CreaseAngle.type:'TANGENT'
#. :src: bpy.types.LineStyleAlphaModifier_Curvature_3D.type:'TANGENT'
#. :src: bpy.types.LineStyleAlphaModifier_DistanceFromCamera.type:'TANGENT'
#. :src: bpy.types.LineStyleAlphaModifier_DistanceFromObject.type:'TANGENT'
#. :src: bpy.types.LineStyleAlphaModifier_Material.type:'TANGENT'
#. :src: bpy.types.LineStyleAlphaModifier_Noise.type:'TANGENT'
#. :src: bpy.types.LineStyleAlphaModifier_Tangent
#. :src: bpy.types.LineStyleAlphaModifier_Tangent.type:'TANGENT'
#. :src: bpy.types.LineStyleColorModifier_AlongStroke.type:'TANGENT'
#. :src: bpy.types.LineStyleColorModifier_CreaseAngle.type:'TANGENT'
#. :src: bpy.types.LineStyleColorModifier_Curvature_3D.type:'TANGENT'
#. :src: bpy.types.LineStyleColorModifier_DistanceFromCamera.type:'TANGENT'
#. :src: bpy.types.LineStyleColorModifier_DistanceFromObject.type:'TANGENT'
#. :src: bpy.types.LineStyleColorModifier_Material.type:'TANGENT'
#. :src: bpy.types.LineStyleColorModifier_Noise.type:'TANGENT'
#. :src: bpy.types.LineStyleColorModifier_Tangent
#. :src: bpy.types.LineStyleColorModifier_Tangent.type:'TANGENT'
#. :src: bpy.types.LineStyleThicknessModifier_AlongStroke.type:'TANGENT'
#. :src: bpy.types.LineStyleThicknessModifier_Calligraphy.type:'TANGENT'
#. :src: bpy.types.LineStyleThicknessModifier_CreaseAngle.type:'TANGENT'
#. :src: bpy.types.LineStyleThicknessModifier_Curvature_3D.type:'TANGENT'
#. :src: bpy.types.LineStyleThicknessModifier_DistanceFromCamera.type:'TANGENT'
#. :src: bpy.types.LineStyleThicknessModifier_DistanceFromObject.type:'TANGENT'
#. :src: bpy.types.LineStyleThicknessModifier_Material.type:'TANGENT'
#. :src: bpy.types.LineStyleThicknessModifier_Noise.type:'TANGENT'
#. :src: bpy.types.LineStyleThicknessModifier_Tangent
#. :src: bpy.types.LineStyleThicknessModifier_Tangent.type:'TANGENT'
#. :src: bpy.types.MeshLoop.tangent
#. :src: bpy.types.CompositorNodeMath.operation:'TANGENT'
#. :src: bpy.types.ShaderNodeMath.operation:'TANGENT'
#. :src: bpy.types.ShaderNodeTangent
#. :src: bpy.types.TextureNodeMath.operation:'TANGENT'
#. :src: bpy.types.OBJECT_OT_bake.normal_space:'TANGENT'
#. :src: bpy.types.SCENE_OT_freestyle_alpha_modifier_add.type:'TANGENT'
#. :src: bpy.types.SCENE_OT_freestyle_color_modifier_add.type:'TANGENT'
#. :src: bpy.types.SCENE_OT_freestyle_thickness_modifier_add.type:'TANGENT'
#. :src: bpy.types.RenderSettings.bake_normal_space:'TANGENT'
#. :src: bpy.types.MaterialTextureSlot.normal_map_space:'TANGENT'
#. :src: bpy.types.MaterialTextureSlot.texture_coords:'TANGENT'
#: source/blender/blenkernel/intern/customdata.c:1261
#: source/blender/nodes/shader/nodes/node_shader_bsdf_anisotropic.c:37
#: source/blender/nodes/shader/nodes/node_shader_bsdf_hair.c:36
#: source/blender/nodes/shader/nodes/node_shader_geometry.c:34
#: source/blender/nodes/shader/nodes/node_shader_tangent.c:32
msgid "Tangent"
msgstr "Тангенс"

Also, I think, that idea "minimise use of gettext context" will be totally wrong, especially for this common words, which can be translated in a variety of ways depending on the situation. I think, every caption in interface must be use context, relating module, in which this caption is used. Thus, there will be no situations when the translation becomes completely useless due to ambiguity and it will not suddenly break with the "fixing" of the translation, referring entirely to another part of the program.

In T43295#424455, @Bastien Montagne (mont29) wrote:

@blend-it (blend-it) I need specific examples (both in PO and UI, with meaning of the different translations for same English word) to handle it correctly. ;)
@Chau (BlenderNavi) Don’t think we need more detail in context here, context is primarily for gettext disambiguation, helping translators is only a secondary goal for them. Also, the :src: comment tells you more than what you may think: since it’s bpy.types, you know that this is data, not action (which would be an operator, bpy.ops..... Further more, the final formating (bpy.types.class.prop_name:'VALUE') tells you that you are dealing with a specific option/value of an Enum property here (the type of a Sequence, i.e. strip).
Indeed, you need to understand a bit of Blender’s internals (at least on its py API level) to sort some cases (or just use the try-and-fix approach), but we really cannot add more complexity to our i18n handling code-wise just to make translators’ life easier, code has to remain reasonably simple and efficient here. ;)

Please add this information to "Blender translation HOWTO" page, at bottom. Very useful help teach translators how understand Blender's internals. :)

@Bastien Montagne (mont29) Screen: http://www.wordreference.com/ said that "projection" is a synonyms for screen, so in English is not so wrong. ;) In Italian, Adobe translate with a word that sound like "reduce color fading to white", "un-color" or "de-color" (scolora). I will use adobe's way because I think Gimp have to reference to Photoshop (and be friendly to photoshop users), and the next step is that gimp have to be the reference for 2D raster graphic stuff. But other ideas/criteria are welcome. :)

@ all
In general, a diffuse disambiguation problem for me is distinguish actions/verbs from objects/nouns (e.g. "Cut" is both "to cut" and "the cut") because in languages that I know, verbs and nouns are translated differently.
I'm not a linguist, is this the same in asiatic and slavic languages? If yes, I think this must have more disambiguation priority than masculine/feminine/neutral or singular/plural perfection. IMHO the criteria is "comprehensibility" not "linguistic perfection" (because on the other hand we must consider overwork for coders and po lightness).

Another highly priority I see, is real different significant (e.g "light" > lamp and weight), with top absolute priority to totally difference between noun/verb (as for "Clip" > "to clip" vs. "the (video) clip"), where a good idea is to use different term ("cut" and "movie"?).

So I think is better to report with priority this 2 kind of problems (noun/verb and synonymy), but also to sensitize code developers to translators problems (with a guideline?).

@Chau done.

@Сергей Яничкин (mingun) eeek… those seems rather odd issues :/ Will need some more time to think about them (why in Hell can’t 'Both' always be translated by Russian word meaning… both? and not 'everything' or other fancy stuff?). Regarding feminine/masculine… currently I suggest to ignore that, it’s really hairy to handle with current system, aside from separating everything, which is not an option.

@blend-it (blend-it)
Actions/verbs vs data/noun is already separated, since all operator labels use specific OPERATOR context. So “Clip” as an action shall already be clearly separated from “Clip” as a data. Checking the current PO it’s already the case, except for one case, afaict. The three current usages of “Light” also are all about “not heavy”, and not about lamp, afaikt (made me realize French translation if off here btw)… Clip/Screen/Frame shall be fixed in rBa7f16c17c260f3.

@Bastien Montagne (mont29) I can't find separate lines in latest POT for:

Frame (border/envelope, not video part)
:src: bpy.types.NodeFrame

Screen (device, not blending mode)
:src: bpy.types.DriverTarget.id_type:'SCREEN'
:src: bpy.types.GPencilStroke.draw_mode:'SCREEN'
:src: bpy.types.Action.id_root:'SCREEN'
:src: bpy.types.KeyingSetPath.id_type:'SCREEN'
:src: bpy.types.OUTLINER_OT_id_remap.id_type:'SCREEN'
(I'm not sure about all of items)

and what about
"Screen: [Operator]" and "Clip: [Operator]" (remark the colon) in po ? Not seem verbs but nouns, also if flagged as Operator, so this is not very effective to distinguish :(

Hi Bastien,

While translating the new strings for 2.79 I've found that the new "Frame [NodeTree]" string doesn't seem to be in use.
It continues to display the time related translation in the Node Editor (at least in Spanish).

Thanks!

other problematic strings I remember:

Child

1. hierarchical relationship
2. secondary particles derivated from real ones

Root

1. base number for some calculation, base bones, base etc...
2. one of the extremes of a hair (root/tip)
3. math operation (as in "square root", or a type of formula/curve derivated from applying such an operation)

Path

1. a location (in a file system, etc.)
2. a trajectory (of an object, particles of a system, etc.)

I've just detected that the string:
"Clearcoat Roughness" does not exist, instead there is a "Clearcoat Gloss" string (the opposite concept?), that exists but it's not in use!
:-/

I've found another string, so I summarize them all here:

Child

1. hierarchical relationship
2. secondary particles derivated from real ones

Root

1. base number for some calculation, base bones, base etc...
2. one of the extremes of a hair (root/tip)
3. math operation (as in "square root", or a type of formula/curve derivated from applying such an operation)

Path

1. a location (in a file system, etc.)
2. a trajectory (of an object, particles of a system, etc.)

Look

1. to look something (used in the mouse actuator)
2. the appearance of something (used in color management's color transforms)

In T43295#444109, @Gabriel Gazzán (gab3d) wrote:

I've just detected that the string:
"Clearcoat Roughness" does not exist, instead there is a "Clearcoat Gloss" string (the opposite concept?), that exists but it's not in use!
:-/

This was changed in the UI recently, maybe the po-files are out of date?

yes, I assume that's the case.
just that I think the new version should not be released with this parameter not translatable
I hope it could be fixed before final release

I summarize strings with ambiguous uses here (sorry for the multiple posts, just thought it'd be easier to keep them all in one message):

Child

1. hierarchical relationship
2. secondary particles derivated from real ones

Root

1. base number for some calculation, base bones, base etc...
2. one of the extremes of a hair (root/tip)
3. math operation (as in "square root", or a type of formula/curve derivated from applying such an operation)

Path

1. a location (in a file system, etc.)
2. a trajectory (of an object, particles of a system, etc.)

Look

1. to look something (used in the mouse actuator)
2. the appearance of something (used in color management's color transforms)

View

1. the string used in color management should be left independent of other uses, as its translation is very specific to that case

The further I'm working down the PO file, the more instances of 'Homonyms' I find. The word 'track' for instance, in case of Motion Tracking, it is already confusing in terms of mixing the meaning of the tracking markers (noun) and tracking action (verb), and then, on top of this, it also means differently as an NLA track in NLA editor. These translations are different in Vietnamese, at least. A typical example is here:

#. :src: bpy.types.MovieTrackingObjectPlaneTracks.active
#. :src: bpy.types.MovieTrackingObjectTracks.active
#. :src: bpy.types.MovieTrackingTracks.active
#: source/blender/editors/space_nla/nla_buttons.c:517
msgid "Active Track"

This example, for me, should be split into two separate sections like this:

msgid "Active Track" {
#. :src: bpy.types.MovieTrackingObjectPlaneTracks.active
#. :src: bpy.types.MovieTrackingObjectTracks.active
#. :src: bpy.types.MovieTrackingTracks.active
msgstr "Dấu Giám Sát Đang Hoạt Động"

#: source/blender/editors/space_nla/nla_buttons.c:517
msgstr "Rãnh Đang Hoạt Động"
}
(for developers: if you need more example please don't hesitate to ask)

I think translators really need a mechanism to insert different translations for different areas where meaning changes. If we already have the mechanism to extract the section of code, where the English string is mentioned, then why don't we use the same mechanism to change the replaced string for different locale?

By the way, where do I find the list where I can add missing English strings in translation file? I think the string 'Average Error: %f' is missing.

#. :src: bpy.types.Image.file_format:'IRIS'
#. :src: bpy.types.ImageFormatSettings.file_format:'IRIS'
#. :src: bpy.types.WipeSequence.transition_type:'IRIS'
msgid "Iris"

both a file type (I suppose, never found .iris filetype, 1 and 2) and eye part (3)
WipeSequence.transition_type:'IRIS' (3) must be separated, or filetype (1 and 2) removed from translated strings (a .jpg is a .jpg, an .iris is an .iris!).

@blend-it (blend-it) thanks, done.

Hi there!

With 2.8 being in Master now, we've started to translate and several of these problems are starting to surface again.

So far I've found problems with the following terms (surely there might be some other ones that will show in time):

• Cycles meaning either: 'the render engine' or 'animation loops'.
• Light meaning either: 'lamp' or 'lightweight'.
• Translation meaning either: 'change in position' or 'to translate to another language'.
• Parent/Child/Children meaning either: 'parent/child of a hierarchy' or 'main/secondary emitted particles'.
• Mirror meaning either: 'a symmetry related thing' or 'the reflective property of a material'.
• Drag meaning either: 'mouse drag' or 'dynamics drag force'.
• Add meaning either: 'the Add blend mode / boolean-type operations' or 'to add a new object'.
• Root meaning either: 'the root of a hair' or 'root falloff type'.
• Volume meaning either: 'volume of some 3D entity' or 'volumetrics, in general' (or 'sound volume' which I know is already independent).
• Smooth meaning either: 'something is smooth' or 'to smooth something'.
• Shift meaning either: 'a key in the keyboard' or 'a displacement in space'.
• Upper/Lower meaning either: 'an upper/lowercase key' or 'a upper/lower limit for a property'.
• World meaning either: 'the virtual 3D universe itself' (like in: "world coordinates") or 'the visible environment around the scene'.
• Front/Back meaning either: 'put something at the front/back' or 'the front/back face of something'. (perfect example of this is seen in the Empty Image options, you have Depth and Side, both using the same stringsfor their options, which shouldn't happen)
• Pixel Size meaning either: 'the size of the pixel' or 'a size measured using pixels as the unit'.
• Strip meaning either: 'a sequencer strip' or 'a hair shape type'.
• Twist meaning either: 'a verb, like in a operator/modifier name' or 'a name, like in particle's twist property'.
• Open meaning either: 'a verb, like in a operator/modifier name' or 'something that is opened, like smoke domain borders'.
• Path meaning either: 'the location of an archive on disk or a blender datablock' or 'the trajectory of a particle/object'.
• Out meaning either: 'Roll/Scale/Ease Out of B-Bones' or 'the direction of a Wipe transition in the video sequencer'.
• Ease In meaning either: 'Ease In of B-Bones' or 'animation Ease In'.

Thanks for listening!

From T61440:

• Flat Projection method / Mesh plane (material preview) / Blur type
• Roughness Material roughness / Particle's non-uniformness
• Project Projection / Place to store proxy data
• Normal Normal Direction / Usual, typical, default / Color blend mode
• New Create new file (file-new) / Adjective for time remapping / Create new selection
• Keying "Keyframing" / Keying node for compositing
• Clip Start / Clip End Camera view / Light distance
• Translation Old international fonts / Moving objects
• Back Position (Background) / Interpolation type
• Emission Emission of light / Emission of particles

Thanks Bastien!
God to see progress in this front. :)

Terms listed by Gabriel Gazzán are also problems in Simplified Chinese UI translation. When will all of these be fixed?

*on particles Parent/Child:
There is a difference in that child particles are "derived" or "interpolated" particles, created and related not to a single parent particle (and its properties), but to several parent particles. I mean, "Parent"particles are particles which are fully independent on its own, but the "child" particles are not standard particles that have been attached to the main ones, in some sort of object hierarchical relationship, but instead are interpolated particles that do not even have their own parameters and therefore use the weighted parameters of nearby main particles to just exist.
So, it's not the same type of hierachical relationship users know from object parent/child relationships, and believe me (at least in Spanish) the particle parent/child terminology used for standard object hierarchies looks weird for this kind of stuff. :-/

"Path", in the context of particles appears in the Render > "Render As" dropdown option (and respective Options Panel Title).

Another one in particles:
"Roughness", because the term used elsewhere: Rugosidad (the Spanish word for roughness) can't be asimilated to several separate elements being in a state of "disorder", as is the case here (i.e. disordered hair strands)

EDIT: Sorry, now I've seen "Roughness" is already listed above.

"Mirror", not relevant any longer. Thanks!

I've found problems in the following two strings:
"Transform" meaning either: 'an item transformation(s)' or 'to transform something'.
"Scale" meaning either: 'an item scale transformation' or 'to scale something'.

I've also found:
"Axis" string is sometimes used as a plural word. (Should be "Axes" in such cases).

Volume at Sidebar --> Adjust --> Sound panel of sequence editor should be displayed as 音量 in Chinese, but it is 体积 (the amount of space that some entity contains or occupies).

Just found another derivative meaning of Volume in Blender.
In file browser, there is a "Volumes" means a single accessible storage area with a single file system, which we use 盘符 or 卷标 to express in Chinese.

@Bastien Montagne (mont29)
I've found the "Cycles" string used for the render engine name is still used as the name of the Cycles F-Modifier, displayed in the UI when you add one of those.

Volume meaning either: 'volume of some 3D entity' or 'volumetrics, in general' (or 'sound volume' which I know is already independent).

Sound volume isn't independent unfortunately. Needs't to be separated too

Cut: divide on 2 parts (sequencer)/ delete and copy (text)

:src: bpy.types.TEXT_OT_cut
:src: bpy.types.VIEW3D_PT_tools_active Tools: 'PARTICLE', 'builtin_brush.Cut'
:src: scripts/startup/bl_ui/space_sequencer.py:670
:src: scripts/startup/bl_ui/space_sequencer.py:735
:src: scripts/startup/bl_ui/space_view3d.py:1562
:src: scripts/startup/bl_ui/space_view3d.py:1588
:src: scripts/startup/bl_ui/space_view3d_toolbar.py:1684

Spaces: Space (keyboard key, character) / Space (area, workspace)

:src: bpy.types.Area.spaces
:src: bpy.types.Text.indentation:'SPACES'
:src: bpy.types.BatchRenameAction.strip_chars:'SPACE'

While translating the new strings for 2.81 I've found that the string "Parents" (used for "main" particles) is now also wrongly used for one of the new "Affect Only" options (Origins/Locations/Parents) of the transform tools toolbar.
Please, that should remain as a separate string.

For example, in Spanish the translation in the particles context would be "Principales", while in the context of transform tools would be "Superiores", so one string is not suitable for the two use cases.

Thanks!