Fix: #0016975: Unnamed type #198

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
5 participants
@grangeway
Contributor

grangeway commented May 27, 2014

No description provided.

@vboctor

This comment has been minimized.

Show comment Hide comment
@vboctor

vboctor May 27, 2014

Owner

-1 - Looking at the code, I don't see why this change necessary.

getLocalizedLabel() calls getLabel(). getLabel() handles the case where the value is not in the enum.

getLabel() and getLocalizedLabel() are inconsistent in checking existed. Once uses hasValue() and the other uses isset().

Owner

vboctor commented May 27, 2014

-1 - Looking at the code, I don't see why this change necessary.

getLocalizedLabel() calls getLabel(). getLabel() handles the case where the value is not in the enum.

getLabel() and getLocalizedLabel() are inconsistent in checking existed. Once uses hasValue() and the other uses isset().

@grangeway

This comment has been minimized.

Show comment Hide comment
@grangeway

grangeway May 27, 2014

Contributor

This Enables fallback to English if the localised version doesn’t exist.

As the user says in the bug report 16975, at the moment, if the translated version doesn’t exist for the enum it displays @10@ for instance

Paul

From: Victor Boctor [mailto:notifications@github.com]
Sent: 27 May 2014 14:55
To: mantisbt/mantisbt
Cc: grangeway
Subject: Re: [mantisbt] Fix: #0016975: Unnamed type (#198)

-1 - Looking at the code, I don't see why this change necessary.

getLocalizedLabel() calls getLabel(). getLabel() handles the case where the value is not in the enum.

getLabel() and getLocalizedLabel() are inconsistent in checking existed. Once uses hasValue() and the other uses isset().


Reply to this email directly or view it on GitHub #198 (comment) .

Contributor

grangeway commented May 27, 2014

This Enables fallback to English if the localised version doesn’t exist.

As the user says in the bug report 16975, at the moment, if the translated version doesn’t exist for the enum it displays @10@ for instance

Paul

From: Victor Boctor [mailto:notifications@github.com]
Sent: 27 May 2014 14:55
To: mantisbt/mantisbt
Cc: grangeway
Subject: Re: [mantisbt] Fix: #0016975: Unnamed type (#198)

-1 - Looking at the code, I don't see why this change necessary.

getLocalizedLabel() calls getLabel(). getLabel() handles the case where the value is not in the enum.

getLabel() and getLocalizedLabel() are inconsistent in checking existed. Once uses hasValue() and the other uses isset().


Reply to this email directly or view it on GitHub #198 (comment) .

@grangeway

This comment has been minimized.

Show comment Hide comment
@grangeway

grangeway May 27, 2014

Contributor

Damien: Refreshed the commit and updated the Mantis bug tracker with a more appropriate bug description.

Contributor

grangeway commented May 27, 2014

Damien: Refreshed the commit and updated the Mantis bug tracker with a more appropriate bug description.

@dregad

This comment has been minimized.

Show comment Hide comment
@dregad

dregad May 28, 2014

Owner

Thanks, but you still don't get my point about long summary lines do you ? ;-)

Owner

dregad commented May 28, 2014

Thanks, but you still don't get my point about long summary lines do you ? ;-)

@rombert

This comment has been minimized.

Show comment Hide comment
@rombert

rombert May 29, 2014

Member

Can this be 'proven' by adding a new test to the existing MantisEnum unit tests?

Member

rombert commented May 29, 2014

Can this be 'proven' by adding a new test to the existing MantisEnum unit tests?

Fix #0016975 Invalid enumeration string value displayed
This fixes an issue where an invalid enumeration string value is displayed
if the localized value does not exist
@grangeway

This comment has been minimized.

Show comment Hide comment
@grangeway

grangeway May 31, 2014

Contributor

Rombert: i've added a test case to the existing MantisEnum unit tests @ https://github.com/mantisbt/mantisbt/pull/198/files to cover this scenario as requested.

Contributor

grangeway commented May 31, 2014

Rombert: i've added a test case to the existing MantisEnum unit tests @ https://github.com/mantisbt/mantisbt/pull/198/files to cover this scenario as requested.

@grangeway

This comment has been minimized.

Show comment Hide comment
@grangeway

grangeway May 31, 2014

Contributor

Damien: Refreshed the commit message for you too

Contributor

grangeway commented May 31, 2014

Damien: Refreshed the commit message for you too

@grangeway

This comment has been minimized.

Show comment Hide comment
@grangeway

grangeway Jun 1, 2014

Contributor

@atrol: would be good to get your input as you was originally discussing this issue with badfiles

Contributor

grangeway commented Jun 1, 2014

@atrol: would be good to get your input as you was originally discussing this issue with badfiles

@atrol

This comment has been minimized.

Show comment Hide comment
@dregad

This comment has been minimized.

Show comment Hide comment
@dregad

dregad Jun 19, 2014

Owner

Just tested this... +1 from me

@vboctor I think adding fallback to English when localized enum element is missing is a useful and user-friendly addition (better to display an untranslated string than @xx@). Or were you challenging the implementation ?

Owner

dregad commented Jun 19, 2014

Just tested this... +1 from me

@vboctor I think adding fallback to English when localized enum element is missing is a useful and user-friendly addition (better to display an untranslated string than @xx@). Or were you challenging the implementation ?

@rombert

This comment has been minimized.

Show comment Hide comment
@rombert

rombert Jul 1, 2014

Member

+1

Member

rombert commented Jul 1, 2014

+1

grangeway added a commit that referenced this pull request Jul 7, 2014

Fix invalid enumeration string value display
Prior to this, an invalid enumeration string value (e.g. @32@) was
displayed if the corresponding localized value did not exist.

This allows fallback to English language for individual enum elements.

Fixes #16975, #198

Signed-off-by: Damien Regad <dregad@mantisbt.org>

@dregad dregad closed this Jul 7, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment