Hi Vetri, No problem! It happens to all of us. :)
I appreciate your efforts in making these files more i18n friendly. Thanks for fixing the issue so quickly. That helps a lot! Talk to you later, Mike On Thu, Jun 26, 2014 at 6:06 AM, Vetrivel Chinnasamy < vetrivel.chinnas...@citrix.com> wrote: > Hi Mike, > > > > Kindly accept my apology for the issue. I have used script to identify > certain pattern of hardcoded strings and fixed them. Some exceptions like > this got escaped from my unit testing also. > > > > I have reverted the changes as suggested and created a patch for review. > > > > Brian/Jessica, Could you please do the needful? > > > > Review Request #23008 <https://reviews.apache.org/r/23008/>. > > > > Kindly accept my apology for inconvenience caused because of this issue. > > > > Thanks. > > > Regards, > > Vetri > > > > P.S: I am reviewing again the externalization code changes committed in > the past to avoid these type of issues. > > > > *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > *Sent:* 26 June 2014 03:56 > *To:* dev@cloudstack.apache.org; Vetrivel Chinnasamy > *Cc:* Brian Federle; Alena Prokharchyk; Jessica Wang > *Subject:* Re: [ACS4.4] i18n problems in Add Primary Storage dialog > > > > By the way, what I was referring to with my proposed hack was just to fix > the two situations ("SR Name-Label" and "Path") by hardcoding the English > back in. > > > > On Wed, Jun 25, 2014 at 2:34 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > > It looks like these issues were introduced in > 182c31899bb353eac66a43ca4e81117c4fd06332 by vetrivelc with regards to > externalizing hardcoded strings. > > > > My guess is that this substitution was done in an automated fashion and > some unintended consequences of the substitution logic occurred. > > > > vetrivelc - Any chance you could take a look at these issues and decide on > a way for us to proceed? This is in 4.4 code (first RC currently planned > for this Friday), so it would be awesome if we could resolve these quickly. > > > > One hack would be for us to just hard code the English words back, but of > course these labels would then be incorrect in other languages (unless, of > course, by coincidence the words happened to be the same in each lang). > > > > Thanks! > > > > > $form.find('.form-item[rel=path]').css('display', 'inline-block'); > > var $required = > $form.find('.form-item[rel=path]').find(".name").find("label span"); > > - > $form.find('.form-item[rel=path]').find(".name").find("label").text("Path:").prepend($required); > > + > $form.find('.form-item[rel=path]').find(".name").find("label").text('label.path'+":").prepend($required); > > > > > $form.find('.form-item[rel=smbUsername]').hide(); > > > $form.find('.form-item[rel=smbPassword]').hide(); > > @@ -15414,7 +15414,7 @@ > > > > > $form.find('.form-item[rel=path]').css('display', 'inline-block'); > > var $required = > $form.find('.form-item[rel=path]').find(".name").find("label span"); > > - > $form.find('.form-item[rel=path]').find(".name").find("label").text("Path:").prepend($required); > > + > $form.find('.form-item[rel=path]').find(".name").find("label").text('label.path'+":").prepend($required); > > > > > $form.find('.form-item[rel=smbUsername]').css('display', 'inline-block'); > > > $form.find('.form-item[rel=smbPassword]').css('display', 'inline-block'); > > @@ -15441,7 +15441,7 @@ > > > > > $form.find('.form-item[rel=path]').css('display', 'inline-block'); > > var $required = > $form.find('.form-item[rel=path]').find(".name").find("label span"); > > - > $form.find('.form-item[rel=path]').find(".name").find("label").text("Path:").prepend($required); > > + > $form.find('.form-item[rel=path]').find(".name").find("label").text('label.path'+":").prepend($required); > > > > > $form.find('.form-item[rel=smbUsername]').hide(); > > > $form.find('.form-item[rel=smbPassword]').hide(); > > @@ -15467,7 +15467,7 @@ > > > > > $form.find('.form-item[rel=path]').css('display', 'inline-block'); > > var $required = > $form.find('.form-item[rel=path]').find(".name").find("label span"); > > - > $form.find('.form-item[rel=path]').find(".name").find("label").text("SR > Name-Label:").prepend($required); > > + > $form.find('.form-item[rel=path]').find(".name").find("label").text(' > label.SR.name'+":").prepend($required); > > > > > $form.find('.form-item[rel=smbUsername]').hide(); > > > $form.find('.form-item[rel=smbPassword]').hide(); > > @@ -15566,7 +15566,7 @@ > > > > > $form.find('.form-item[rel=path]').css('display', 'inline-block'); > > var $required = > $form.find('.form-item[rel=path]').find(".name").find("label span"); > > - > $form.find('.form-item[rel=path]').find(".name").find("label").text("Path:").prepend($required); > > + > $form.find('.form-item[rel=path]').find(".name").find("label").text('label.path'+":").prepend($required); > > > > On Wed, Jun 25, 2014 at 11:06 AM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > > Hi, > > > > I noticed a couple i18n-related issues in the Add Primary Storage dialog: > > > > 1) label.path shows up literally as label.path (instead of Path) > > > > 2) label.SR.name shows up literally as label.SR.name (instead of SR > Name-Label) > > > > I looked at the applicable i18n/l10n files and all looked well. > > > > Once I looked in the system.js file, however, I saw the following line > (with respect to label.SR.name): > > > > $form.find('.form-item[rel=path]').find(".name").find("label").text(' > label.SR.name'+":").prepend($required); > > > > There is no i18n lookup here. The same problem exists for label.path (only > there are more occurrences of that type of code). > > > > I'm not sure why the code was written this way and I'm hoping we can > resolve this before Friday's first 4.4 RC build. > > > > Any thoughts on this? I've directly CCed a few people who work on the GUI > regularly. > > > > Thanks! > > > > -- > *Mike Tutkowski* > > *Senior CloudStack Developer, SolidFire Inc.* > > e: mike.tutkow...@solidfire.com > > o: 303.746.7302 > > Advancing the way the world uses the cloud > <http://solidfire.com/solution/overview/?video=play>*™* > > > > > > -- > *Mike Tutkowski* > > *Senior CloudStack Developer, SolidFire Inc.* > > e: mike.tutkow...@solidfire.com > > o: 303.746.7302 > > Advancing the way the world uses the cloud > <http://solidfire.com/solution/overview/?video=play>*™* > > > > > > -- > *Mike Tutkowski* > > *Senior CloudStack Developer, SolidFire Inc.* > > e: mike.tutkow...@solidfire.com > > o: 303.746.7302 > > Advancing the way the world uses the cloud > <http://solidfire.com/solution/overview/?video=play>*™* > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
