flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maurice Amsellem <maurice.amsel...@systar.com>
Subject RE: [DISCUSS] Discuss Release Apache Flex SDK Installer 3.0 - RC6
Date Mon, 10 Mar 2014 18:52:40 GMT
>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.


-----Message d'origine-----
De : omuppi1@gmail.com [mailto:omuppi1@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 <aharui@adobe.com> wrote:

> On 3/10/14 11:14 AM, "OmPrakash Muppirala" <bigosmallm@gmail.com> wrote:
> >On Mon, Mar 10, 2014 at 11:08 AM, Alex Harui <aharui@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,

> >
> >
> >> 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.


> -Alex

View raw message