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>*™*

Reply via email to