Closed
Bug 928174
Opened 11 years ago
Closed 7 years ago
[Meta][l12y] Truncated and Overlapping text in 1.2
Categories
(Firefox OS Graveyard :: Gaia, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: delphine, Unassigned)
References
Details
(Whiteboard: LocRun1.2)
Although less frequent and different than in 1.1(see Bug 892075), there are still text truncation issues throughout 1.2.
This happens across different 1.2 shipping locales, and includes some English occurrences as well.
Let's track these here to get a better view of where it needs to be solved and how we can solve this
Reporter | ||
Updated•11 years ago
|
Whiteboard: LocRun1.2
Reporter | ||
Updated•11 years ago
|
Summary: [Meta][l12y] Truncated text in 1.2 → [Meta][l12y] Truncated and Overlapping text in 1.2
Reporter | ||
Updated•11 years ago
|
Updated•11 years ago
|
Comment 1•11 years ago
|
||
I’m not sure I understand what’s going on here… Are all these bugs regressions? I.e. did those same strings fit in 1.1?
Bug 927785 might have helped, but this bug is only about list items in the Settings app. Can we have an idea of what apps and app components are concerned by these truncations?
As an example: how much would it help if we reduced the font-size in the title bars? I think it would greatly improve the readability, even for English — and we could even reduce the title bar height, thus getting more vertical screen estate for the content… Is there a bug for that by any chance?
Comment 2•11 years ago
|
||
Kaze, this bug covered some truncation issues in title bars: bug #908300. Not sure that's exactly what you're looking for.
Comment 3•11 years ago
|
||
Thanks for the pointer Stephany, but how many of the bugs tracked in this meta-bug would be solved by bug 908300?
Or to put it another way: as a developer, what would be the most efficient way for me to help to reduce these truncations? If we can identify which application or which UI component is raising the most truncation issues, we could focus on those and do our best to fix them properly.
Besides, I think we should watch these most-impacted apps or UI components closely to make sure we (= developers) haven’t introduced regressions in the latest branch. I’m a bit scared that l10n-related regressions are not enough taken in consideration during the development process, and I’m rather confident we could improve this by relying on some of our most talented volunteers (hi Théo! ^^) if we knew where to look at.
I hope this clarifies my question a bit. Sorry for being unclear. :-/
Updated•11 years ago
|
Comment 4•11 years ago
|
||
Trying again to start the discussion on this issue… let me rephrase. I think there are three main reason why we have truncated or overlapping strings:
A: some text containers are just too short; they are hardly large enough for English and there’s no extra space for longer locales (e.g. Latin locales), which should be considered as a UX bug. Bug 908300 is a good example.
B: some text containers have been reduced since the last branch, which should be considered as a *regression* imho. Bug 927785 is a good example of such a regression.
C: some localizers do not test on HVGA devices, and don’t pay enough attention to the string sizes. This can happen a lot and there’s not much we can do to prevent it — it’s just part of the localization process.
Now the question is: how many of this long list of bugs would fall in each bucket?
As a developer, I’m mostly worried about A: and B: here — we should do what it takes to avoid breaking the work of our l10n contributors. Delphine, would it be possible to file two meta bugs for that? One for too small containers, one for unwanted container width reduction? And do you think it’d be worth it?
Flags: needinfo?(lebedel.delphine)
Comment 5•11 years ago
|
||
Another reason that Flod pointed out is that we reuse our l10n strings too much in different contexts — e.g. in the link and in a header for the Settings app. This is a mistake that we don’t do with XUL localization.
As Flod suggested, a good start would be to have a naming convention for entities: XXX-button, XXX-title, XXX-label.
Comment 6•11 years ago
|
||
(In reply to Fabien Cazenave [:kaze] from comment #5)
> As Flod suggested, a good start would be to have a naming convention for
> entities: XXX-button, XXX-title, XXX-label.
Note that having "coding guidelines for .properties file" would also help us in other areas:
* More readable files: I count at least 6 different ways of writing a simple statement like X=Y, if you don't believe me check settings.properties.
* Help with the constant lack of l10n comments. Knowing if the label is used for a message, a header or a button etc. would help me understand if I'm looking at a verb or a noun in English, and would also help me identify a string that needs QA without looking at the code.
Reporter | ||
Comment 7•11 years ago
|
||
Sorry for the late reply. Let's wait and see what comes out of our meeting this Thursday before we go forwards with this :)
Flags: needinfo?(lebedel.delphine)
Reporter | ||
Comment 8•7 years ago
|
||
Old bug, closing as WORKSFORME
Reporter | ||
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•