I don't think this is going to work. If I bake in en_US, the english strings will appear for a bit before the localized strings appear.
I think I'll try to only load co-packaged en_US strings if something goes wrong in the early stages. -Alex On 3/10/14 11:57 AM, "Alex Harui" <aha...@adobe.com> wrote: >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 >>> >>> >
