Current: in <locale>/lang-reg/mozapps/update/updates.properties.po #: remain msgid "remain" msgstr "" the string "remain" is position-fixed, will always be placed after a remaining time (duration), like this: "09:30 remain" Problem: this cause a problem in translation, as it can't be fitted in some languages' grammar -- for instance, in Thai language we need to have the duration at the back. "เหลืออีก 09:30" Expected: a string for showing remaining time should use %S, so translators can make it more localisable.

Mic or Axel, can I ask you to look at this?

No idea how that code is hooked up. We'll need help from someone that knows the code here.

How it's hooked up is "heinously complexly." In http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/locales/en-US/chrome/mozapps/update/updates.properties&rev=1.37&mark=37#37 the #1 is replaced with the time and the #2 is replaced with the value of the "remain" string. So what Arthit needs is already possible, just switch timeFormat to "; #2 #1" (or possibly some more switching of the semicolon and the order of progressFormat, too) but someone clearly needs to write some l10n notes in that block of formatting.

(In reply to comment #3) > the #1 is replaced with the time and the #2 is replaced with the value of the > "remain" string. So what Arthit needs is already possible, just switch > timeFormat to "; #2 #1" (or possibly some more switching of the semicolon and > the order of progressFormat, too) what does semicolon ';' means here ? so in our Thai case, we can just modify timeFormat in updates.properties ?

Yes, you should test that it looks like you want, though.

I'M not familar with this code at all but here are a few possible things to check on and kick around. I did a quick couple of mxr searches for "time" stuff across all locales and it appears that no one has ever tried changing it, so there might be a bit of risk in taking the patch. If we do take the patch we should definitely do some testing to see if we get the desired affects. As far as I can tell it looks like the only place that these time format values are used is in the progress dialog. It looks like it might really be "longTimeFormat" and/or "shortTimeFormat" that needs to change. "timeFormat" actually doesn't get used in nsProgressDialog.dtd or anywhere else as far as I can tell. I guess that might be good for the question raised in comment 4 about trying to figure out what the semicolon means. If we don't need to change "timeFormat", then we don't need figure out what that semicolon means ;-) The bad part of this is that these other xxxTimeFormat's seem to only have parameters for hour:min:seconds and not the flexibility of swapping around the "remain" string and the time values. Here is what came up in searches /th/toolkit/chrome/mozapps/update/updates.properties (View CVS log or CVS annotations) * line 33 -- longTimeFormat=#1:#2:#3 * line 34 -- shortTimeFormat=#2:#3 * line 37 -- timeFormat=; #1 #2 /th/toolkit/chrome/global/nsProgressDialog.dtd (View CVS log or CVS annotations) * line 97 -- <!-- LOCALIZATION NOTE (longTimeFormat): * line 106 -- <!ENTITY longTimeFormat "#1:#2:#3"> * line 107 -- <!-- LOCALIZATION NOTE (shortTimeFormat): * line 117 -- <!ENTITY shortTimeFormat "#2:#3"> * line 122 -- xxxTimeFormat strings defined above). You can omit "#1" if you don't and here is the code that seems affected http://bonsai-l10n.mozilla.org/cvsblame.cgi?file=/l10n/th/toolkit/chrome/global/nsProgressDialog.dtd&mark=&rev=1.1 96 <!ENTITY unknownTime "ไม่ทราบ"> 97 <!-- LOCALIZATION NOTE (longTimeFormat): 98 99 This string is used to format elapsed/remaining times when the 100 time exceeds 1 hour in length. 101 102 #1 will be replaced by the number of hours 103 #2 will be replaced by the number of minutes 104 #3 will be replaced by the number of seconds --> 105 106 axel 1.1 <!ENTITY longTimeFormat "#1:#2:#3"> 107 <!-- LOCALIZATION NOTE (shortTimeFormat): 108 109 This string is used to format elapsed/remaining times when the 110 time is less than 1 hour in length. Note that you can leave 111 "#1" out of this string to omit the leading "00:" if you so choose. 112 113 #1 will be replaced by the number of hours 114 #2 will be replaced by the number of minutes 115 #3 will be replaced by the number of seconds --> 116 117 <!ENTITY shortTimeFormat "#2:#3"> 118 <!-- LOCALIZATION NOTE (completeMsg): 119 120 This string is displayed when the download is complete. The insert 121 "#1" is replaced by the elapsed time, formatted according to the 122 xxxTimeFormat strings defined above). You can omit "#1" if you don't 123 want the elapsed time in the message. 124 125 #1 will be replaced by the elapsed time 126 #2 will be replaced by the size of the file in Kilobytes --> more searching to see of I can understand how this works.

Chris, AFAICT this is about a comment change explaining how things are hooked up. I see no risk in taking that.

phil, > How it's hooked up is "heinously complexly." ++ ;-) after a couple of pass I still don't understand how this all might work correctly, I think I found a couple of instances of where this might be in use in the ja-* builds http://mxr.mozilla.org/l10n/source/ja-JP-mac/toolkit/chrome/mozapps/update/updates.properties to answer the question: > what does semicolon ';' means here ? In ja builds the semicolon (;) has been replaced with dash (-) 36 # (^^; rateFormat?BSec "(3.4/4.7MB" 37 rateFormat = (#1 38 progressFormat = #1#2 39 # (^^; remainingTime, remain "- 残り 01:15)" 40 timeFormat = - #2 #1) Line 973 of http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/mozapps/update/content/updates.js&mark=&rev=1.83 has a comment about how the en-US and example download progress message will look: "3.4 of 4.7MB; 01:15 remain" the semicolon in "timeFormat" just separates the size information from the time information or something like [size_info][[;] [time_info]] [remain_string] ja has decided on a format for the full download progress message that looks more like [size_info] [[;|-|other_separator] [残り|remain_string]] [time_info] so Arthit, I guess you get to decide on the character you want for the separation and that gets put on the front of the value for "timeFormat"

Chris and Axel, we now use DownloadUtils.jsm to provide date / time strings - Bug 414326. Note that the summary of this bug changed from "remain" string should use %S for easy L10n to Add l10n notes explaining update.properties time and progress replacement vars

Also, bug 412793 seems to cover the remaining issues described by the new summary

Fun. The original summary was somewhere between worksforme (the intended result was already possible) and wontfix (just sticking in a %S somewhere wouldn't have fixed it, other than in the place where there already was one, practically speaking), my new summary is invalid, since there hadn't been any time and progress replacement vars in update.properties for five days by the time I changed it.

Update from Thai L10n team. Refer to Comment 8, we've decided to use timeFormat= #2 #1 in similar way to ja one.

attachment shows how ja looks. it appears that it actually possible to show something like [remain_string] [- time_info] [ bandwidth/footprint_info ] if you also wanted to do it that way. I'm not sure if just changing timeFormat gets you this effect. There may be another change that is needed.