Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translation of line design names #2095

Closed
Kebap opened this issue Oct 29, 2018 · 1 comment · Fixed by #2106
Closed

Translation of line design names #2095

Kebap opened this issue Oct 29, 2018 · 1 comment · Fixed by #2106
Assignees
Labels
i18n & l10n internationalization and localization

Comments

@Kebap
Copy link
Contributor

Kebap commented Oct 29, 2018

Brief summary of issue / Description of requested feature:

Current names of line designs are both used for display to user as well as internal state. Therefore, can't be translated properly. They need to be refactored to seperate state and display.

Steps to reproduce the issue / Reasons for adding feature:

See comments in following PR for comparison and more detail:
#2089 (comment)
Affected files are at least T2DMap.cpp and TLuaInterpreter.cpp

Expected result of feature

Translated Mudlet should show translated names of line designs. Functionality should not be affected.

Extra information, such as Mudlet version, operating system and ideas for how to solve / implement:

SlySven put a proposal for improvement under above link as well

Example for English design names in translated (German) Mudlet:
image

@Kebap Kebap added the i18n & l10n internationalization and localization label Oct 29, 2018
Kebap added a commit to Kebap/Mudlet that referenced this issue Oct 29, 2018
@Kebap Kebap changed the title Updates to translate line designs Translation of line design names Oct 29, 2018
@Kebap
Copy link
Contributor Author

Kebap commented Nov 4, 2018

@SlySven announced already working on this, with a solution about to be ready in the next few days. Yay!

SlySven added a commit to SlySven/Mudlet that referenced this issue Nov 5, 2018
Changes the TRoom class to store the detail about the style of line as the
Qt::PenStyle enum that is used when it is actually drawn (saves a few
bytes per custom exit line)!  Concurrently change the 2D map UI that
adjusts this setting on both new custom exit lines being drawn and existing
lines selected by the UI to separate the text used to describe the style
from this value so that the text can be translated for other GUI languages
without breaking the code.  Enhance the control (a `QComboBox`) used for
this so that it has icons with a visual representation of each style!

Revise the Lua function `addCustomLine` to bring the error reporting up to
current UI style - including detection some error conditions that were not
previously reported (included whether there was the exit that the custom
line was to be added to show). Also the target room who's location was used
as the end-point for a single segment line was not being checked to confirm
that it existed and was in the same area as the room that the exit line was
being drawn from. Alternatively, when a table of tables of coordinate
triplets {x, y, z} was provided there was previously no proper validation
that they all existed and were numbers to be used as coordinates...

I also discovered that TLuaInterpreter::dirToString was not producing the
right `QString`s necessary for numeric arguments for the normal exit
direction to work in the two lua functions that used it (`addCustomLine`
and `setExitWeight`) I have corrected it and updated the callers of it to
now return the right normal exit strings needed for each of them.

To validate whether there is actually an exit in the direction that the
lua addCustomLine function is told is a little complicated so I have added
a `(bool) TRoom::hasExitOrSpecialExit(const QString&, const bool) const`
method that does this so that addCustomLine can return a run-time error
(nil + error message) if the given exit does not already exist.

In some places in the TLuaInterpreter custom line functions and the
`T2DMap::paintEvent()` method non-const method were being used to access
the details of the custom exit lines - as this takes longer and runs the
risk of changing the data when it should not be being changed I have
switched to using the read only or constant `at(...)`/`value(...)` methods
rather than the read/write or non-constant `operator[...]` method where
practical.

I have also made each custom exit line be drawn as a polyline rather than
a series of single segments - this is more effiecent I think and it means
that the dotted/dashed pattern effect "goes around" each corner rather than
restarting on each segment which looks better IMHO - draw a multi-segment
line and move one of the vertexes towards the end and you will see the
differences. 8-)

This should close Mudlet#2095 !

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
SlySven added a commit to SlySven/Mudlet that referenced this issue Nov 5, 2018
Changes the TRoom class to store the detail about the style of line as the
Qt::PenStyle enum that is used when it is actually drawn (saves a few
bytes per custom exit line)!  Concurrently change the 2D map UI that
adjusts this setting on both new custom exit lines being drawn and existing
lines selected by the UI to separate the text used to describe the style
from this value so that the text can be translated for other GUI languages
without breaking the code.  Enhance the control (a `QComboBox`) used for
this so that it has icons with a visual representation of each style!

Revise the Lua function `addCustomLine` to bring the error reporting up to
current UI style - including detection some error conditions that were not
previously reported (included whether there was the exit that the custom
line was to be added to show). Also the target room who's location was used
as the end-point for a single segment line was not being checked to confirm
that it existed and was in the same area as the room that the exit line was
being drawn from. Alternatively, when a table of tables of coordinate
triplets {x, y, z} was provided there was previously no proper validation
that they all existed and were numbers to be used as coordinates...

I also discovered that TLuaInterpreter::dirToString was not producing the
right `QString`s necessary for numeric arguments for the normal exit
direction to work in the two lua functions that used it (`addCustomLine`
and `setExitWeight`) I have corrected it and updated the callers of it to
now return the right normal exit strings needed for each of them.

To validate whether there is actually an exit in the direction that the
lua addCustomLine function is told is a little complicated so I have added
a `(bool) TRoom::hasExitOrSpecialExit(const QString&, const bool) const`
method that does this so that addCustomLine can return a run-time error
(nil + error message) if the given exit does not already exist.

In some places in the TLuaInterpreter custom line functions and the
`T2DMap::paintEvent()` method non-const method were being used to access
the details of the custom exit lines - as this takes longer and runs the
risk of changing the data when it should not be being changed I have
switched to using the read only or constant `at(...)`/`value(...)` methods
rather than the read/write or non-constant `operator[...]` method where
practical.

I have also made each custom exit line be drawn as a polyline rather than
a series of single segments - this is more effiecent I think and it means
that the dotted/dashed pattern effect "goes around" each corner rather than
restarting on each segment which looks better IMHO - draw a multi-segment
line and move one of the vertexes towards the end and you will see the
differences. 8-)

This should close Mudlet#2095 !

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
SlySven added a commit to SlySven/Mudlet that referenced this issue Nov 5, 2018
Changes the TRoom class to store the detail about the style of line as the
Qt::PenStyle enum that is used when it is actually drawn (saves a few
bytes per custom exit line)!  Concurrently change the 2D map UI that
adjusts this setting on both new custom exit lines being drawn and existing
lines selected by the UI to separate the text used to describe the style
from this value so that the text can be translated for other GUI languages
without breaking the code.  Enhance the control (a `QComboBox`) used for
this so that it has icons with a visual representation of each style!

Revise the Lua function `addCustomLine` to bring the error reporting up to
current UI style - including detection some error conditions that were not
previously reported (included whether there was the exit that the custom
line was to be added to show). Also the target room who's location was used
as the end-point for a single segment line was not being checked to confirm
that it existed and was in the same area as the room that the exit line was
being drawn from. Alternatively, when a table of tables of coordinate
triplets {x, y, z} was provided there was previously no proper validation
that they all existed and were numbers to be used as coordinates...

I also discovered that TLuaInterpreter::dirToString was not producing the
right `QString`s necessary for numeric arguments for the normal exit
direction to work in the two lua functions that used it (`addCustomLine`
and `setExitWeight`) I have corrected it and updated the callers of it to
now return the right normal exit strings needed for each of them.

To validate whether there is actually an exit in the direction that the
lua addCustomLine function is told is a little complicated so I have added
a `(bool) TRoom::hasExitOrSpecialExit(const QString&, const bool) const`
method that does this so that addCustomLine can return a run-time error
(nil + error message) if the given exit does not already exist.

In some places in the TLuaInterpreter custom line functions and the
`T2DMap::paintEvent()` method non-const method were being used to access
the details of the custom exit lines - as this takes longer and runs the
risk of changing the data when it should not be being changed I have
switched to using the read only or constant `at(...)`/`value(...)` methods
rather than the read/write or non-constant `operator[...]` method where
practical.

I have also made each custom exit line be drawn as a polyline rather than
a series of single segments - this is more effiecent I think and it means
that the dotted/dashed pattern effect "goes around" each corner rather than
restarting on each segment which looks better IMHO - draw a multi-segment
line and move one of the vertexes towards the end and you will see the
differences. 8-)

This should close Mudlet#2095 !

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
SlySven added a commit that referenced this issue Nov 17, 2018
Changes the TRoom class to store the detail about the style of line as the
Qt::PenStyle enum that is used when it is actually drawn (saves a few
bytes per custom exit line)!  Concurrently change the 2D map UI that
adjusts this setting on both new custom exit lines being drawn and existing
lines selected by the UI to separate the text used to describe the style
from this value so that the text can be translated for other GUI languages
without breaking the code.  Enhance the control (a `QComboBox`) used for
this so that it has icons with a visual representation of each style!

Revise the Lua function `addCustomLine` to bring the error reporting up to
current UI style - including detection some error conditions that were not
previously reported (included whether there was the exit that the custom
line was to be added to show). Also the target room who's location was used
as the end-point for a single segment line was not being checked to confirm
that it existed and was in the same area as the room that the exit line was
being drawn from. Alternatively, when a table of tables of coordinate
triplets {x, y, z} was provided there was previously no proper validation
that they all existed and were numbers to be used as coordinates...

I also discovered that TLuaInterpreter::dirToString was not producing the
right `QString`s necessary for numeric arguments for the normal exit
direction to work in the two lua functions that used it (`addCustomLine`
and `setExitWeight`) I have corrected it and updated the callers of it to
now return the right normal exit strings needed for each of them.

To validate whether there is actually an exit in the direction that the
lua addCustomLine function is told is a little complicated so I have added
a `(bool) TRoom::hasExitOrSpecialExit(const QString&, const bool) const`
method that does this so that addCustomLine can return a run-time error
(nil + error message) if the given exit does not already exist.

In some places in the TLuaInterpreter custom line functions and the
`T2DMap::paintEvent()` method non-const method were being used to access
the details of the custom exit lines - as this takes longer and runs the
risk of changing the data when it should not be being changed I have
switched to using the read only or constant `at(...)`/`value(...)` methods
rather than the read/write or non-constant `operator[...]` method where
practical.

I have also made each custom exit line be drawn as a polyline rather than
a series of single segments - this is more effiecent I think and it means
that the dotted/dashed pattern effect "goes around" each corner rather than
restarting on each segment which looks better IMHO - draw a multi-segment
line and move one of the vertexes towards the end and you will see the
differences. 8-)

This should close #2095 !

Revised to make addCustomLine & setExitWeight not case sensitive for exit dir

In fact have converted the TRoom custom exit line data members use a lower
case key for "Normal" exit directions and go through all the places where
those keys were used. Also make the change in the binary map data format
20 (and above). As it was convenient to do so, I have also changed it so
that the custom line colour is stored as a `QColor` instead of a
`QList<int>` of RGB components.

The addCustomLine and setExitWeight lua functions now treat a wider range
of strings as being for "Normal" exit directions in a case insensitive
manner - there is a small possibility that this may clash with strings used
for "Special" exits if they use a full English word for the exit direction
(with or without hyphens for diagonal exits)...

In testing the lua addCustomLine command I found that adding a new line to
a room that did not previously have one produced a weirdly visible line
that only showed up at some zoom levels and was very thin.  It turned out
that this is because there was not a call to TRoom::calcRoomDimensions()
after adding the line and the TRoom::{min|max}_{x|y} members (which are
updated by that) are used during the T2DMap::paintEvent().

Whilst I was working in this area of code I decided I could also provide
the missing lua function `removeCustomLine`...

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i18n & l10n internationalization and localization
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants