cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: [ACS4.4] i18n problems in Add Primary Storage dialog
Date Thu, 26 Jun 2014 16:13:56 GMT
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.chinnasamy@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message