NetTalk Central

Author Topic: Runtime Language Translation Issues and more.  (Read 6163 times)

Rob Kolanko

  • Sr. Member
  • ****
  • Posts: 253
    • View Profile
Runtime Language Translation Issues and more.
« on: January 19, 2013, 09:34:26 AM »
Sometimes this Forum will not show the post to logged in users. The “Runtime Language Translation Issues”  post in now blank, but you can see it when not signed in. Do not know why, but I have reposted it here. Bruce, there are some major issues here which are easily reproducible in my example. I hope you have a chance to look at these issues soon as I have been requesting help on these issues since November. 

I recompiled my NT6.51 example of the issues to NT7.02. It appears that the attempted alert message translation fix of NT6.51 was not included in NT7 which is good because it caused more problems than it fixed.  The following problems still exist. Compile the attached Web3 clarion 8 application using NT7.02.

Alert Messages do not show accented characters.
Start the example, change the language to French and attempt to log in with an invalid password. The accented characters of the popup alert message are incorrect.

Using a variable date picture for browse field will result in no date picture in the locator field for this column.
In the example, I changed the date field’s picture to p_web.site.datepicture for the date field column of the MailboxBrowseControl procedure. Start the example, select English language and log in (with user and password of “demo”) . Browse the mailboxes and you see that the date field picture of the mailbox browse is MMM DD, YYYY. However if you click on the date column header the locater field is a number not a date. If you log in and select French language and the date picture will change to DD/MM/YYYY, but the locator field is a still a number and not a date.
I have found if the template picture field for browse column date field does not contain a literal date picture (e.g. ‘@D3’), then the locator field picture for the date column is number. This is my number one issue, hopefully it is not to hard to fix.

Accented characters in the record delete message are incorrect.
Start the example, select French language and log in (with user and password of “demo”). Browse the mailboxes, select a record press the delete button,  the accented characters of the popup alert message are incorrect.

Browses or Forms in a pop-up will not appear if the title of the pop up contains an apostrophe.
Start the example, select English language and log in (with user and password of “demo”). Browse the mailboxes, select a record press the change button,  on the form press the “Display Popup” button and a pop-up form will appear. Log out, select French language and log in. Browse the mailboxes, select a record press the change button,  on the form press the “Display Popup” button a pop-up form and a pop-up message will not appear. This is because the title of the popup message translates in French to phrase with an apostrophe.

Thank-you,
Rob


[attachment deleted by admin]

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11250
    • View Profile
Re: Runtime Language Translation Issues and more.
« Reply #1 on: January 19, 2013, 09:25:43 PM »

>> Using a variable date picture for browse field will result in no date picture in the locator field for this column.

fixed for 7.03. The fix is quite extensive though so probably not something I'd back-port to NT6.
I've added a new "Browse Column Type" (ie in addition to String, Button and Procedure) called "Date". This allows you to be completely explicit that the column is a date, and it doesn't have to examine the picture in order to determine that.

>> Browses or Forms in a pop-up will not appear if the title of the pop up contains an apostrophe.

fixed for 7.03

>> Accented characters in the record delete message are incorrect.

I've tweaked the JavaScript files, and templates etc, so that the Confirm message is now dynamically created by the browse, rather than using the built-in JavaScript CONFIRM command. This will give us more flexibility going forward, and also allows for more translation options.
So, on the template, on the Browse, Delete button tab, you can now enter the text for the buttons, the message, and the header (where before it was just the header). As a bonus the confirmation message is now styled so you will have more control over the look.

Note: you example also pointed out the need to explicitly call the translation method for the Delete Confirmation message. I'm doing that automatically now so you can (and should) remove the manual call there.

example css;
#message_confirm {
color: red;
}


>> Alert Messages do not show accented characters.

Along the same lines as the Confirm message, the ALERT command is now bypassed in favor of a styled dialog.

example css;
#message_alert{
color: blue;
}


cheers
Bruce
« Last Edit: January 21, 2013, 05:38:48 AM by Bruce »

Rob Kolanko

  • Sr. Member
  • ****
  • Posts: 253
    • View Profile
Re: Runtime Language Translation Issues and more.
« Reply #2 on: January 21, 2013, 09:01:22 AM »
Hi Bruce,
Looking forward to 7.03. If I understand correctly, the JavaScript message and confirm will be replaced with a Jquery type popup. Presumably, in mobile mode, these messages will appear as a regular web page?
Will the new record delete message allow the programmer to create a customized message that includes session variables based on the users record selection?  For example, instead of a generic “Do you wish to delete the selected customer?”,  the message could be coded to say: “Do you wish to delete customer, Capesoft?”, provided that customer name is in the key or retrieved after record selection.

Thank-you
Rob

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11250
    • View Profile
Re: Runtime Language Translation Issues and more.
« Reply #3 on: January 21, 2013, 10:16:39 PM »
Hi Rob,

>> Will the new record delete message allow the programmer to create a customized message that includes session variables based on the users record selection?

unfortunately no. The message is set when the browse opens, and the whole "confirmation" thing is done completely in the browser when the user presses the button. there's no server interaction, no "pre-delete" sort of thing.

Your suggestion though is intriguing - and _possibly_ a custom message for each row could be included on the page. However that makes the page a bit bigger (which is bad) so I'm not 100% sure if the trade-off is worth it. This won't be in 7.03, but might be a possibility for later on if we want to go down that road.

cheers
Bruce

Rob Kolanko

  • Sr. Member
  • ****
  • Posts: 253
    • View Profile
Re: Runtime Language Translation Issues and more.
« Reply #4 on: January 22, 2013, 06:10:42 AM »
Hi Bruce,
With a popup, the user can still see the selected record, thus the trade off for a larger page is not worth it.
IMO
Rob

Rob Kolanko

  • Sr. Member
  • ****
  • Posts: 253
    • View Profile
Re: Runtime Language Translation Issues and more.
« Reply #5 on: February 11, 2013, 01:59:06 PM »
Hi Bruce,
Rats, I thought the translation issues were all fixed, but I found another problem that could affect English language UI as well. Unfortunately the  "Browses or Forms in a pop-up will not appear if the title of the pop up contains an apostrophe." fix did not extend to pop-ups for look-ups on fields. If you have a NetWebForm field with a table look-up in a pop-up window and the title for the pop-up has an apostrophe, the pop-up will not appear.
I have modified the example program to demonstrate the problem. Start the example, select English language and log in (with user and password of “demo”). Browse the mailboxes, select a record press the change button,  on the form, select the "Forward" tab, press the look-up button and the pop-up for the field look up will appear.  Log out, select French language and log in. Browse the mailboxes, select a record press the change button,  on the form, select the "Forward" tab, press the look-up button and a pop-up message will not appear. This is because the title of the popup message translates in French to a phrase with an apostrophe.

Rob

[attachment deleted by admin]

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11250
    • View Profile
Re: Runtime Language Translation Issues and more.
« Reply #6 on: February 12, 2013, 01:16:51 AM »
thanks Rob. fixed in 7.06

cheers
Bruce

Rob Kolanko

  • Sr. Member
  • ****
  • Posts: 253
    • View Profile
Re: Runtime Language Translation Issues and more.
« Reply #7 on: February 12, 2013, 08:48:30 AM »
Translation issue with new NT7 file uploader. I can make run time translation the text of the buttons (Add File, Start, Clear, etc.) used in the file uploader, however I can not find where I can make a runtime translation of the file upload status: "Waiting...", "Uploaded", "Failed", and "Cancelled".  Is there a site variable for these strings?
Putting translated values for the strings in my translation table, is not translating the text, so I do not believe that p_web.translate is being called for these strings. 
Thanks,
Rob

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11250
    • View Profile
Re: Runtime Language Translation Issues and more.
« Reply #8 on: February 13, 2013, 11:03:01 PM »
these are options for the control that can be added to loc:options.

right click on the procedure in question, and choose "source".
search for 'ntupload'
it's on a line like this;

  packet = clip(packet) & p_web.jQuery('#' & lower('MailboxesFormControl_' & p_web._nocolon('MAI:MailBoxPicture') & '_value_div'),'ntupload',loc:options)

There's an embed just above it where you can tweak the loc:options. In NT7 this is easier to do than before.
The code looks something like this;

loc:options = p_web.SetOption(loc:options,'OptionName','OptionValue')

the method is very smart because it allows you to both add a new option, or override one of the "default" options I am setting just above there. So if, for example, you wanted to override just the autoupload option in code, you could do

loc:options = p_web.SetOption(loc:options,'autoUpload',1)

and it'll tweak that option value, even if it already exists in the log:options string.

the options you are looking for are called;

uploadedText
failedText
waitingText
cancelledText


so you might have

loc:options = p_web.SetOption(loc:options,'uploadedText','opgesteuur')
loc:options = p_web.SetOption(loc:options,'failedText','vrot')
loc:options = p_web.SetOption(loc:options,'waitingText','ek wag')
loc:options = p_web.SetOption(loc:options,'cancelledText','gemoord')


remember loc:options contains "JavaScript" and JavaScript is case sensitive. So be careful with the option names.

Cheers
Bruce

Rob Kolanko

  • Sr. Member
  • ****
  • Posts: 253
    • View Profile
Re: Runtime Language Translation Issues and more.
« Reply #9 on: February 14, 2013, 01:04:02 AM »
Bruce,
I found that the replacement text must be double quoted to work. e.g.
loc:options = p_web.SetOption(loc:options,'uploadedText','"opgesteuur"')

Othewise the uploader is not displayed at all.

Rob

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11250
    • View Profile
Re: Runtime Language Translation Issues and more.
« Reply #10 on: February 20, 2013, 04:24:54 AM »
yes, I agree. I've tweaked the method so that it does that automatically, but if you include the " you should be ok.

also note the new option (7.06)

uploadingText

Cheers
Bruce


Rob Kolanko

  • Sr. Member
  • ****
  • Posts: 253
    • View Profile
Re: Runtime Language Translation Issues and more.
« Reply #11 on: February 27, 2013, 08:07:16 AM »
>>I agree. I've tweaked the method so that it does that automatically, but if you include the " you should be ok.
Nope, if the " are left on the strings in NT7.06, the script crashes. No problem, I just removed the " from my code. Nothing to fix here.

Another language issue that I wish I had reported earlier. Alert messages that have an apostrophe are not displayed in NT7.05 or NT7.06.  French language uses the apostrophe allot. If I use the method "p_web.jsParm" on the string when copying to loc:alert, then the message is displayed.
loc:alert=p_web.jsParm(message string, variable, or function)

Unfortunately, then the message that appears at the top of the screen contains a backslash by the apostrophe. I suggest inspecting all generated Javascript code and if user text is being included then p_web.jsParm method must be applied.

Rob

Rob Kolanko

  • Sr. Member
  • ****
  • Posts: 253
    • View Profile
Re: Runtime Language Translation Issues and more.
« Reply #12 on: March 04, 2013, 08:26:26 AM »
Hi Bruce,
Maybe I have confused the issue, but please acknowledge the bug reported above.
Thanks
Rob

bruce2

  • Full Member
  • ***
  • Posts: 108
    • View Profile
    • Email
Re: Runtime Language Translation Issues and more.
« Reply #13 on: March 04, 2013, 11:35:51 PM »
we gotta keep these threads shorter <g>.
this forum software doesn't like long threads for some reason.

But no, you didn't cloud the issue, and the issue has been fixed for 7.07.
(I did it in a slightly different way to you, but the result is the same, well the same in the sense that mine works without the \ being displayed.)

>> ... and if user text is being included then p_web.jsParm method must be applied.

In very specific cases yes, but in all cases no. One of the fun bits of HTML, and JavaScript is the various encodings used in various places.

Cheers
Bruce