Bug 970655 - JON Documentation Warning for long fields in UI
Summary: JON Documentation Warning for long fields in UI
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Documentation   
(Show other bugs)
Version: JON 3.2
Hardware: Unspecified Unspecified
Target Milestone: GA
: JON 3.3.0
Assignee: Jared MORGAN
QA Contact: Mike Foley
Keywords: Documentation
Depends On:
TreeView+ depends on / blocked
Reported: 2013-06-04 13:59 UTC by Mike Thompson
Modified: 2015-08-10 01:23 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
No docs impact. Relates to translation limitations in the UI.
Last Closed: 2014-11-16 23:19:09 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Mike Thompson 2013-06-04 13:59:23 UTC
Section Number and Name: 
This is mainly to document the constraint we have with:
Bundle Translation length issues

Describe the issue: 
On the d3 charts the right-hand min,max, avg label for chart legend is too long in German and overwrites the value; unfortunately, SVG text elements require a x,y coordinate (which makes it fixed) because this is vector based graphics with no rendering engine like html (although we do have a 100% width function).

We have room for probably about 6 characters after that we start pushing the label into overwriting the value and it doesn't look good. Obviously, if we use abbreviations in these fields if it is an issue. 

The specific message bundle keys I'm referring to here are 

chart_title_avg_label = Avg
chart_title_min_label = Min
chart_title_peak_label = Max

Suggestions for improvement:

Comment 1 Deon Ballard 2013-12-12 17:18:28 UTC
I am reassigning this to the localization team.

Comment 2 Angela Garcia 2014-09-08 04:44:26 UTC
Hi All,

The use of abbreviations in some fields should be fine to work around this.
It would be ideal if a note to the translator can be included so that we all are aware of the issue.

Comment 3 Jared MORGAN 2014-11-12 04:05:59 UTC
(In reply to Angela Garcia from comment #2)
> Hi All,
> The use of abbreviations in some fields should be fine to work around this.
> It would be ideal if a note to the translator can be included so that we all
> are aware of the issue.

I'm not sure whether keeping this as a Documentation component is correct. It seems to relate to UI fields, therefore wouldn't the correct component be UI regardless of translation impact.

Comment 4 Mike Thompson 2014-11-12 15:39:29 UTC
Of course the UI could always chop the field down but then the translator would be unaware of what they entered would get chopped and how far. This probably has different impacts in different languages (meaning 3 chars may be fine for english but not good enough for japanese). Also characters are misleading it should really, be pixels as other languages have symbols that are larger and its the pixel widths that push the limits not characters.

[This is getting rendered as SVG (on a graph) not HTML so we don't have all fancy things that we can do with HTML/CSS here.]

For these reasons, I do think it should be kept as a Documentation component.

Comment 5 Jared MORGAN 2014-11-12 23:14:31 UTC
So we can keep it as a Documentation component, but as it is more documenting a limitation, can we close it off?

Or better still, document the issue/decision in a project workspace somewhere that the Translators and Engineers use so it doesn't get lost in BZ?

Comment 6 Mike Thompson 2014-11-13 22:55:00 UTC
Oh sure. Close it.

Thanks Jared.

Comment 7 Jared MORGAN 2014-11-16 23:19:09 UTC
Closing this off as NOTABUG, because it is more guidance for translators than an actual bug in the product.

Note You need to log in before you can comment on or make changes to this bug.