Hide Forgot
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 Messages.properties: chart_title_avg_label = Avg chart_title_min_label = Min chart_title_peak_label = Max Suggestions for improvement:
I am reassigning this to the localization team.
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.
(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.
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.
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?
Oh sure. Close it. Thanks Jared.
Closing this off as NOTABUG, because it is more guidance for translators than an actual bug in the product.