upgraded to Firefox ver. 27.0 - this sls pkg recipe only works for windows 64-bit + lang en_US on "C:" drive

Ok, this is a long and very loaded starting point. And probably not a good idea to start with such a long discussion, I know, so sorry folks. Maybe this discussion does not belong into a PR but into an issue?
 
Please bear in mind and bear with me that although I am discussing this with regard to the specifics of the Firefox sls pkg recipe, but it really is a much more generic and all encompassing topic related to sls pkg files for windows in general.

But the existing firefox.sls file had/has at least three assumptions, that I would like to discuss and then a fourth point or question I have about "the proper" handling of software updates to windows pkgs in salt in general.


Assumption #1 64-bit windows target
it is a firefox.sls 'as-is' is a pkg file that will only install correctly 'as-is' on a 64-bit version of windows, even though FF itself is only a 32-bit program. the difference between this same installer being installed on a win32 bit system and a win64 bit system is mainly in the actual Path in which it get's installed, as in "C:\Program Files (x86)\Mozilla Firefox\" on a 64-bit windows and "C:\Program Files\Mozilla Firefox\" on a 32-bit windows.
How is this best handled? Does this become a separate branch for win32 targets and another one for win64 targets?


Assumption #2 language en_US
I am swiss (german speaking swiss) and work in the UK. my windows pkgs need to be en_GB, which has a different download URL, and if and when I release to others in Germany or Switzerland it needs to be de_DE
Hos is this best handled? Does this become another few branches like de_DE (Germany) de_AT (Austria) de_CH (Switzerland)? Although not all software producers use these designations, MS often use a lcid code , and others use other codes, so how will/would a sensible language/country+language branch naming look like?
Here are the MS lcid codes http://msdn.microsoft.com/en-gb/goglobal/bb964664.aspx , so the UK english in MS parlance would be 0809 not en_GB , and US english is 0409 not en_US,  and Swiss German would be 0807 not de_CH, and Austrian German would be 0c07 not de_AT, and German german would be 0407 not de_DE.
This choice of languages is specific tyo the software vendor, Mozilla have adopted one convention, Microsoft another, how should this best be abstracted into the salt pkg use for windows software recipes?
Is my assumption right that we'll end up having a 'branch" for each language or each country+language ? Starts to look to me like a very fragmented tree? But in order to cater to different languages that software is being provided in that is likely a necessity?


Assumption #3 target drive is "C:"
The firefox.sls script assumes that the user will have their "Program Files" folder on the C: drive, this is likely the case in 99.99% of cases, but a cleaner and safer practice is to use the target systems variable %ProgramFiles%, %ProgramFiles(x86)%, %ProgramFilesW6432%, %SystemDrive% and %SystemRoot%, 
Would it make sense and be practical to use these variables throughout windows sls pkg scripts instead of hardoded assumptions?

Fourth point how many PRs should be done to forward a pkg to a new version?
I am blaming being swiss and a bit of a perfectionist and on the pedantic side of things. ;-) I would like to get the pkg to generally go up in the version increments that the publisher release public versions. So in the case of FF this would go from 26 to 27.0 to 28.0 to 29.0 to 29.0.1, that is 5 PRs , so that the person using this can chose to upgrade to whichever version they decided they need to work for them. In a case like FF this may or may not make sense. But with the major UI changes between ver 28 and ver 29 in FF, this might exactly be what some folks would want or expect?
If this is so, what would my workflow or my PRs need be for this? Can I just make one commit per new version of FF and then request a single PR to get all this into the master? Do I need to "tag" anything , to make it useful or possible to chose a specific latest or intermediate version of the repo sls pkg file? I am afraid that I am a real newbie when it comes to github and collaboration using PRs, so not sure how to achieve the right granularity of versions in what the PR adds to the salt/salt-winrepo at the end of it all.

Having written this long rant about generic questions on how to update and structure sls pkg recipes for windows in the first place, I now think, I should have probably entered this somewhere else? Trying to get this all agreed and the PR merged  is a very different thing from the actual diffs on this PR which are probably very non controversial and could be merged right away for now.

Well live and learn ...