The mixed-up use of the word 'Lines' with a hidden meaning 'number of', and the original meaning
Closed, ArchivedPublic

Description

I'm hitting another wall with this word at the moment, negotiating the pathways to resolve these multiple meaning problems.

As listed, this world is being used in multiple places:

#. :src: bpy.types.Text.lines # hidden 'number of'
#. :src: bpy.types.MaterialHalo.use_lines # hidden 'number of'
#. :src: bpy.types.MotionPath.lines # original meaning (line)
#. :src: bpy.types.IMPORT_SCENE_OT_obj.use_edges # original meaning (line)
#. :src: bpy.types.TEXT_OT_scroll.lines # hidden 'number of'
#. :src: bpy.types.TEXT_OT_scroll_bar.lines # hidden 'number of'
#: scripts/startup/bl_ui/properties_animviz.py:90 # original meaning (line)
#: scripts/startup/bl_ui/properties_material.py:614 # hidden 'number of'
#: scripts/startup/bl_ui/space_view3d.py:3509 # hidden 'number of'
msgid "Lines"
msgstr "(Số) Đường/Dòng"

Following are images supporting these findings:

  1. Places where usage has hidden meaning 'number of':
  2. Number of grid lines

  • Number of halo lines

  1. Places where usage showed the original meaning of 'straight lines':
  2. Import of waterfront OBJ format

  • Calculate motion path for poses


Use this test file if you do not want to recreate

I honestly still think the job of separating the meanings are down to the translators but there must be a mechanism allowing them to do so. This task might vary between languages.

Details

Type
Bug
Philipp Oeser (lichtwerk) triaged this task as Incomplete priority.May 8 2018, 1:49 PM

Why not stick to the plural? Sorry, absolutely no native speaker, but những Dòng wouldnt work?
Otherwise, changes in a couple of places need to happen (not to speak of external documentation...)

No, if this was OK I'd have come up a solution myself already. If you've noticed my translation, I already use brackets, slashes to add possible meanings to the translation, at least allowing users to 'GUESS'. But this is, to me, a not very clean and clearcut as it should be. I've already grepped the list of all possible contexts I could use and tried

  • msgctx "Material"

for the 'Halo' instance, but it didn't make any difference.

I do not yet know the inside working of the translation code, so this idea is just a gabbled thought in my head. Maybe all the definitions of CONTEXT strings should be placed outside, in a text file, and allowing translators to add their own definitions to it. The coding will just follow the context to insert the appropriate translation beneath it. Would this make life much easier for the translation portion of the code? I personally think I could live with this - of course, this is relating to homophones (words with multiple meanings).

There should be a tool which expose (visually) those contexts, say in translation editing mode, which allows translators to visualise the context a field (English text) is being used and be able to match their translations to that appropriately.

Bastien Montagne (mont29) closed this task as Archived.Thu, Jul 12, 4:32 PM

Am sorry, but this looks much more like feature request than actual bug report, we do not handle that here. Further more, dev time for i18n aspect of the project is pretty much NULL currently, so… we’ll have to live with what we have for now.