Bug 1001473
| Summary: | [ja_JP][Admin Portal] String 'Network Provider' broken into two lines in 'New Host' dailog. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Lijun Li <lijli> |
| Component: | ovirt-engine-webadmin-portal | Assignee: | Lior Vernia <lvernia> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Yuko Katabami <ykatabam> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.3.0 | CC: | acathrow, bazulay, danken, ecohen, iheim, lijli, lpeer, lvernia, masayag, nyechiel, qe-i18n-bugs, Rhev-m-bugs, yeylon, ykatabam |
| Target Milestone: | --- | Keywords: | i18n |
| Target Release: | 3.4.0 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | network | ||
| Fixed In Version: | org.ovirt.engine-root-3.4.0-17 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-12 14:04:21 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Network | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1026487 | ||
| Attachments: | |||
|
Description
Lijun Li
2013-08-27 06:46:29 UTC
Created attachment 790796 [details]
String 'Network Provider' broken into two lines in 'New Host' dailog
Hello Li, I could use a clarification, is "Network Provider" translated into a single word in Japanese? Or could it be that the translated Japanese string is missing a space character? Thanks, Lior. (In reply to Lior Vernia from comment #2) > Hello Li, > > I could use a clarification, is "Network Provider" translated into a single > word in Japanese? Or could it be that the translated Japanese string is > missing a space character? > > Thanks, Lior. Hi Lior, No need to add space within the translated Japanese string and checked it in Zanata, the translation is: ネットワークプロバイダー , it's a single word and should be displayed in one line. Thanks, Robert. @Yuko - we have a similar issue discussed in bug 1000946; is there any way to make the ja-JP translation for "Network Provider" shorter or split it to two words? (In reply to Einav Cohen from comment #4) > @Yuko - we have a similar issue discussed in bug 1000946; > is there any way to make the ja-JP translation for "Network Provider" > shorter or split it to two words? @Einav - It would be better if we can change it to: ネットワーク プロバイダー Should I insert "\n" or pilcrow (¶) in Zanata to break the line where it is appropriate? Created attachment 795768 [details]
new-line
(In reply to Yuko Katabami from comment #5) > (In reply to Einav Cohen from comment #4) > > @Yuko - we have a similar issue discussed in bug 1000946; > > is there any way to make the ja-JP translation for "Network Provider" > > shorter or split it to two words? > > @Einav - It would be better if we can change it to: > > ネットワーク > プロバイダー > > Should I insert "\n" or pilcrow (¶) in Zanata to break the line where it is > appropriate? Hi Yuko, first of all - if it makes sense to put a simple single white-space, it is preferable. if white-space doesn't make sense, please put a line-break symbol in the relevant location within the translation, as you suggested. with regards to the exact newline character to be used: in https://bugzilla.redhat.com/show_bug.cgi?id=1001428#c4, Daniel has suggested to put the line break character ('\n\'), which is indeed the character that eventually need to appear in the .properties (text) file generated from Zanata; however, I saw that in Zanata there is a usage of a gray pilcrow character (see attachment 795768 [details]) - it seems that this gray pilcrow character represents the '\n\' character, so this is what you should be using. (In reply to Einav Cohen from comment #7) > (In reply to Yuko Katabami from comment #5) > > (In reply to Einav Cohen from comment #4) > > > @Yuko - we have a similar issue discussed in bug 1000946; > > > is there any way to make the ja-JP translation for "Network Provider" > > > shorter or split it to two words? > > > > @Einav - It would be better if we can change it to: > > > > ネットワーク > > プロバイダー > > > > Should I insert "\n" or pilcrow (¶) in Zanata to break the line where it is > > appropriate? > > Hi Yuko, first of all - if it makes sense to put a simple single > white-space, it is preferable. if white-space doesn't make sense, please put > a line-break symbol in the relevant location within the translation, as you > suggested. > > with regards to the exact newline character to be used: in > https://bugzilla.redhat.com/show_bug.cgi?id=1001428#c4, Daniel has suggested > to put the line break character ('\n\'), which is indeed the character that > eventually need to appear in the .properties (text) file generated from > Zanata; however, I saw that in Zanata there is a usage of a gray pilcrow > character (see attachment 795768 [details]) - it seems that this gray > pilcrow character represents the '\n\' character, so this is what you should > be using. Hi Einav, I have changed the string using the gray pilcrow as suggested. Please see attached screenshot. There are two strings of "Network Provider": Resource IDs networkProvider and networkProviderButtonLabel Please let me know if both need to be fixed or only one of these. I will ask our zh-CN translator about the #1001428. Created attachment 795779 [details]
Network Provider strings in Zanata
(In reply to Yuko Katabami from comment #8) > ... > > Hi Einav, > I have changed the string using the gray pilcrow as suggested. > Please see attached screenshot. > There are two strings of "Network Provider": > Resource IDs networkProvider and networkProviderButtonLabel > Please let me know if both need to be fixed or only one of these. > @Lior - which one(s) should be changed: networkProvider, networkProviderButtonLabel or both? networkProviderButtonLabel is what appears in the left-hand tab when adding a new host (i.e. what this bug was opened about). networkProvider appears at the top of the Import Networks dialog (accessible from Networks main tab --> Import). No bug was opened for the string there overrunning the listbox, but I suspect there might be a length problem there as well, so it might be a good idea to change that as well (although that can also be fixed by more spacing if that's preferable). (In reply to Lior Vernia from comment #12) > networkProviderButtonLabel is what appears in the left-hand tab when adding > a new host (i.e. what this bug was opened about). > > networkProvider appears at the top of the Import Networks dialog (accessible > from Networks main tab --> Import). No bug was opened for the string there > overrunning the listbox, but I suspect there might be a length problem there > as well, so it might be a good idea to change that as well (although that > can also be fixed by more spacing if that's preferable). Hi Lior, I checked the Import Networks window (Networks main tab --> Import) and I also think the length might be a problem (but I don't have the latest environment at hand and mine shows this window in unlocalized thus unable to see the issue). In this case, adjusting the spacing is preferable. I removed the pilcrow from networkProvider in Zanata, but left the pilcrow with networkProviderButtonLabel. Please let me know if there is any issue with it. I can file a new bug for networkProvider (to extend the space) during the upcoming L10N QA event starting from next Tuesday, if required. Hello Yuko, Yes, if there proves to be a problem with the Import Networks dialog I'd appreciate you opening a bug, as we are currently in a development phase where little can be done without a related bug. Lior. (In reply to Lior Vernia from comment #14) > Hello Yuko, > > Yes, if there proves to be a problem with the Import Networks dialog I'd > appreciate you opening a bug, as we are currently in a development phase > where little can be done without a related bug. > > Lior. Hi Lior, Sure. No problems. Thank you for your suggestion. Hi Yuko, if this one is completed (i.e. ready to be pulled from Zanata), can you please move the BZ to POST? Thanks. (In reply to Einav Cohen from comment #16) > Hi Yuko, if this one is completed (i.e. ready to be pulled from Zanata), can > you please move the BZ to POST? > Thanks. Hi Einav, Yes, it has been fixed. I only changed one with Resource ID networkProviderButtonLabel. I will check the other one during the QA event and file a separate bug if it is problematic. Thank you. Created attachment 799730 [details]
Line break point is not fixed, and a space was inserted.
Checking with zanata developers for the solution. I was suggested by Zanata developer to insert u200B character where I want to wrap the text. It is fixed in zanata now and need to check again when the next build becomes available. To expand a little for future reference: I have advised using a zero-width space to specify the point where the string should be broken when there is insufficient width. Zero-width space is unicode code point 200B, which can usually be input with a key combination. e.g. I am using Red Hat Enterprise Linux and I can hold Ctrl+Shift, press u, 2, 0, 0, b, then release Ctrl and Shift to insert the character. In Zanata editor at the moment the zero-width space is displayed as a black dot, but in a downloaded .po file it is correctly represented. The same should be the case for .properties files, but I have not checked specifically. Note that it does not appear possible to copy-paste a zero-width space from the Zanata editor at the moment, so I recommend always using a key combination as described above. (In reply to David Mason from comment #21) > To expand a little for future reference: I have advised using a zero-width > space to specify the point where the string should be broken when there is > insufficient width. > > Zero-width space is unicode code point 200B, which can usually be input with > a key combination. e.g. I am using Red Hat Enterprise Linux and I can hold > Ctrl+Shift, press u, 2, 0, 0, b, then release Ctrl and Shift to insert the > character. > > In Zanata editor at the moment the zero-width space is displayed as a black > dot, but in a downloaded .po file it is correctly represented. The same > should be the case for .properties files, but I have not checked > specifically. > > Note that it does not appear possible to copy-paste a zero-width space from > the Zanata editor at the moment, so I recommend always using a key > combination as described above. Hi David, Thank you very much for your thorough explanation, and sorry about my insufficient information in my previous comment. @Einav, Translation is updated following the suggestion by David. It is ready to pull. I move this status back to POST. Verified it's NOT fixed on is21 build 3.3.0-0.31.beta1.el6ev Please refer to the attached screenshot. Created attachment 819559 [details]
Not Fixed on is21
(In reply to Lijun Li from comment #25) > Verified it's NOT fixed on is21 build 3.3.0-0.31.beta1.el6ev > > Please refer to the attached screenshot. @Einav, I would like to check with you if the fixed translation was pulled or not. If it was no pulled, that's fine but if it was and then did not fix the problem, it means that inserting u200B character did not work. Please let me know. Kind regards, Yuko Created attachment 828935 [details]
updated translation pulled from Zanata
(In reply to Yuko Katabami from comment #27) > (In reply to Lijun Li from comment #25) > > Verified it's NOT fixed on is21 build 3.3.0-0.31.beta1.el6ev > > > > Please refer to the attached screenshot. > > @Einav, > > I would like to check with you if the fixed translation was pulled or not. > If it was no pulled, that's fine but if it was and then did not fix the > problem, it means that inserting u200B character did not work. > > Please let me know. > > Kind regards, > > Yuko Hi Yuko, it seems that the translation has been updated properly (i.e. the "/n" character has been properly replaced with the "/u200B" character - see attachment 828935 [details]), however indeed it seems that it hasn't affected the rendered text in the application. @Lior - can you please assist us and find out what is the exact character that should be written within the string in the *_ja_JP.properties file that will result in a newline within the section-title label? (In reply to Einav Cohen from comment #29) > (In reply to Yuko Katabami from comment #27) > > (In reply to Lijun Li from comment #25) > > > Verified it's NOT fixed on is21 build 3.3.0-0.31.beta1.el6ev > > > > > > Please refer to the attached screenshot. > > > > @Einav, > > > > I would like to check with you if the fixed translation was pulled or not. > > If it was no pulled, that's fine but if it was and then did not fix the > > problem, it means that inserting u200B character did not work. > > > > Please let me know. > > > > Kind regards, > > > > Yuko > > Hi Yuko, it seems that the translation has been updated properly (i.e. the > "/n" character has been properly replaced with the "/u200B" character - see > attachment 828935 [details]), however indeed it seems that it hasn't > affected the rendered text in the application. > @Lior - can you please assist us and find out what is the exact character > that should be written within the string in the *_ja_JP.properties file that > will result in a newline within the section-title label? Thank you Einav. I will also speak with David Mason or other Zanata engineers about this and update if we can find other solution. Just checked with damason but there is no other solution for this. Is it possible to widen the pane? (In reply to Yuko Katabami from comment #32) > Just checked with damason but there is no other solution for this. > > Is it possible to widen the pane? [changing Whiteboard to 'network' for now] @Lior - thoughts? see comment #29, comment #32 for possible solutions, please let us know what you think. thanks. Sorry, I probably missed your original NEEDINFO somehow. I played around with this a little on Firefox 22. Seems like lines aren't broken according to spaces at all when Japanese letters are concerned; I tried inserting actual spaces (with nonzero width) and the string still got broken at the same spot. I found that adding a CSS property "word-break: keep-all" to the containing HTML element does respect spacing when breaking (including the zero width space), but this should be applied in the generic left tab widget (to correct this everywhere and not just for this specific dialog and tab), and I'm not knowledgeable enough in CSS to know what harm this might cause on other browsers. I'll play around a little and push a patch when I'm happy with the results. (In reply to Lior Vernia from comment #34) > Sorry, I probably missed your original NEEDINFO somehow. I played around > with this a little on Firefox 22. Seems like lines aren't broken according > to spaces at all when Japanese letters are concerned; I tried inserting > actual spaces (with nonzero width) and the string still got broken at the > same spot. > > I found that adding a CSS property "word-break: keep-all" to the containing > HTML element does respect spacing when breaking (including the zero width > space), but this should be applied in the generic left tab widget (to > correct this everywhere and not just for this specific dialog and tab), and > I'm not knowledgeable enough in CSS to know what harm this might cause on > other browsers. I'll play around a little and push a patch when I'm happy > with the results. Many thanks, Lior - I appreciate it. The patch I pushed should fix this on Firefox and on IE for all dialog left tabs, as far as I could tell without breaking anything in Western languages. It seems that the CSS property is not supported on Chrome (verified) and possibly on Safari (didn't check), haven't found an easy fix for those. P.S. zero-width space should in general keep on being inserted within such words as line-break "hints". (In reply to Lior Vernia from comment #36) > The patch I pushed should fix this on Firefox and on IE for all dialog left > tabs, as far as I could tell without breaking anything in Western languages. Many thanks, Lior. > It seems that the CSS property is not supported on Chrome (verified) and > possibly on Safari (didn't check), haven't found an easy fix for those. For Chrome, it indeed seems to be a known issue: https://code.google.com/p/chromium/issues/detail?id=141792 Verified Not fixed on av8 build： 3.4.0-0.16.rc.el6ev. Please see the attached screenshot. Created attachment 893580 [details]
Not fixed av8_Network Provider
I think it was incorrectly marked as ON_QA in av8, I think it missed that build. Verified on latest av9 build, it's still Not Fixed. Build: 3.4.0-0.21.el6ev Let's solve it in 3.5, then. Created attachment 899307 [details]
Host dialog, Japanese
See my screenshot from 3.4.0-0.21.el6ev. Looks okay to me. This is on Firefox 22, verified on Firefox 26 as well.
Lijun Li, could you provide more details on why this bug is not yet fixed? It looks like fixed to me too. @Robert, wonder why it did not show this fix on your environment. I found out why --- I opened Robert's environment with google-chrome and it looked unfixed but when I opened it in Firefox, it looks perfectly fine. We should change the status to VERIFIED. Created attachment 899379 [details]
Confirmed the fix on 3.4.0-0.21 using Firefox
With Comment 45 and Comment 49, also verified on Firefox (version: ESR 17.0.10), it's FIXED, moving to VERIFIED. Closing as part of 3.4.0 |