OK, I will try embedding en_US.properties. On 3/10/14 11:52 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote:
>>I propose that we ship the entire en_US with the app. > >That sounds like a good compromise (between all locales downloaded and >all locales embedded) > >I think that we can assume that the target "audience" for the installer >are developers, so they have enough knowledge of English to understand >simple error messages. > >Falling back to the English embedded locale in case something goes wrong >early would be a good option. > > >Maurice > >-----Message d'origine----- >De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash >Muppirala >Envoyé : lundi 10 mars 2014 19:42 >À : dev@flex.apache.org >Objet : Re: [DISCUSS] Discuss Release Apache Flex SDK Installer 3.0 - RC6 > >On Mon, Mar 10, 2014 at 11:32 AM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> On 3/10/14 11:14 AM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: >> >> >On Mon, Mar 10, 2014 at 11:08 AM, Alex Harui <aha...@adobe.com> wrote: >> > >> >> As currently written, we can fail before we get the localized >>strings. >> >> Also, there is very little chance that all of the current locales >> >>will get updated. Some locales are already missing strings. >> >> >> >> >> >I thought you mentioned that you are embedding en_US in the app? >> Right now, just the "Install Log" and "Close" button labels. Maybe it >> is just me, but the odds that we'll fail this early seem really low. >> Yes, there will be other blank labels in the app, but I'm having >> trouble justifying the work of restoring the full en_US runtime locale >> and then figuring out how to toss it and start anew when the >> properties files get loaded. >> > >The Installer is 2.3 MB on windows. The en_US properties file is 9 KB. >Embedding this whole file into the app will cause a negligible increase >in the file size. Also, I the chance that we will want to change the >strings without pushing a release is extremely low. I propose that we >ship the entire en_US with the app. > > >> >> > >> > >> >> I considered replacing the privacy notice with an error message, >> >>but it looks like the code will still call the abort tracker, so I >> >>ruled out that idea. >> >> >> >> >> >Not sure what the error message label and abort tracker have to do >> >with each other? Also, if the installation failed, we should track >>it, right? >> To display an error message I need to find space in the UI to display >> a message. Again, I'm having trouble justifying re-designing the UI >> for these scenarios and debugging layout issues and other visual >> issues in subsequent Rcs. There is already space in the UI to display >> the privacy link, so I thought of repurposing that space, but like you >> said, we should track this failure, so we shouldn't repurpose that part >>of the UI. >> > >The tracker has nothing to do with the privacy link. The tracker is a >1x1 pixel html component that is not visible to the user. > >I am proposing adding a line just above the privacy link. That will >never be visible until there is an error in the first screen (installer >config loading error, locale loading error, etc.) > > >> > >> > >> >> Right now I'm leaning towards auto-displaying the log. >> >> >> >> >> >What is the point of auto-displaying the log if the locales are not >> >downloaded yet? The console log will not have any useful error >>message. >> >At least, showing a hardcoded message in en_US might give users some >> >clue as to what happened. >> I hard coded a few more English strings for these low probability >> scenarios so the log contains something useful. I just tried it. It >> looks reasonable to me. >> > >Okay, sounds reasonable. I can spend some time on making the UI changes >when I have time. Feel free to leave it when you are satisfied. > >Thanks, >Om > > >> >> -Alex >> >>
