I have no problem with the way this was done. I don't think we plan on moving away from a shell-based PKGBUILD anytime soon, and might as well use what is available to us.

The problem here is that language packs in firefox come and go. I usually check the array of languages and then rebuild the package on version updates. Changing this PKGBUILD to interpreted sources means we have to update everything in 2 places.

I understand the extra effort part. The reason what prompted my comment is that some AUR users try to use the same pattern (of this non-standard, non-documented "back door" to makepkg functionality) and then complain that why the AUR website cannot understand it?

That's one thing that there are no plans to move away from the current "source PKGBUILD" way of doing things in makepkg, but the standard was made for a reason - that there can be and there are code other than makepkg that can understand (correctly) PKGBUILDs. For example while the AUR implementation of the parser understand the standard version, "eval" obviously brakes it.

I cannot (and shouldn't) comment on how much extra effort is to update the PKGBUILD every releasse. My rewrite was about 15 minutes (with some reading to refresh by bash scripting knowledge:)

It is one of the stremgth of ABS that PKGBUILDs are just Bash scripts and we can use any Bash feature to simplify the PKGBUILD.

Actually, according to the PKGBUILD man page, only the build() function has to be bash. If there'll _ever_ be an alternative implementation, it only has do bash in build(), not anywhere else.

I know there are many things that can make a PKGBUILD easier to maintain, relying on these "undocumented" solutions using the fact that makepkg itself is a bash script. Like commenting in the variable fields, that wouldn't be allowed according to the docs, and is still used so many times.

Just felt, that these tricks are most of the time unnecessary (useful but unnecessary) - if there's a situation that absolutely cannot be handled without "eval"-ing the control variables, then the PKGBUILD specs are not adequate. I haven't come across such situation yet, though.... If you think e.g. "evaling" is important, let's get it included in the standard.

Still, this is all an observation, nothing more.

What I like less is when a PKGBUILD depends on the system where it is sourced.
This is not the case here though, sourcing the PKGBUILD will always result in the same variables, no matter where it is run.
So AUR could just do that and display everything correctly for firefox-i18n.

The reason why AUR doesn't source PKGBUILDs, but interprets them, is because of security reasons. This is not a real issue for official packages, because developers have access to the server anyways and can trash the machine in several other ways if they want to. For AUR PKGBUILDs, everyone can apply for an account and upload PKGBUILDs.

Oh, of course, I never realized that. Hmm.. There is really no way to source in a secure way? Like maybe restricting the system/environment the PKGBUILD is sourced in, or things like that.
I noticed namcap invoked bash in as special way : http://projects.archlinux.org/?p=namcap.git;a=blob;f=parsepkgbuild;hb=HEAD
8 export PATH=/tmp/parsepkgbuild; exec /bin/bash --noprofile --norc -r << EOF
And -r is apparently a restricted shell mode.

That "sourcing" was exactly what I wanted to get to: currently this eval "backdoor" works with makepkg, but only because it is actually breaking the PKGBUILD format.
If there is a movement to secure makepkg more, this backdoor is most likely to be closed, but the standardized behaviour will of course will continue to work.

If you say that it is not a problem for official packages but it's a problem for AUR : the people uploading to AUR learn/copy from the official packages! Check out for example the AUR bug report  FS#12645 
Can we honestly say, that there is a different standard for official packages then for AUR ones? As much as I know, AUR packages can be included into the community repo (that's kinda "official", isn't it?) but also can be relegated back to AUR - so could use "eval" when I'm in "community" but once I back in AUR I have to replace it back to manual listing? That does not make much sense to me.

What I found funny is that according to you, AUR has to be right, and official packages have to be wrong.
The only real definition of PKGBUILD is whatever can be fed to makepkg and results in a working package. Using eval does not break the PKGBUILD format at all, that is non-sense. It only breaks AUR.
Of course in practice, packagers try to write sane PKGBUILDs, resulting in sane packages, and a number of conventions and usages have been made for practical reasons. But that's it.

The "Arch Packaging Standards" would be better named "Packaging guidelines". And this document does not look official at all, and can be edited by anyone. Also, see the difference :
man makepkg
If you need to create any custom variables for use in your build process, it is recommended to name your custom variables with an _ (underscore) prefix. This will prevent any possible name clashes with internal makepkg variables. For example, to store the base kernel version in a variable, use something similar to $_basekernver.

vs

# Do not introduce new variables into your PKGBUILD build scripts, unless the package cannot be built without doing so, as these could possibly conflict with variables used in makepkg itself. If a new variable is absolutely required, prefix the variable name with an underscore (_) e.g
_customvariable=
The AUR cannot detect the use of custom variables and so cannot use them in substitutions. This can most often be seen in the source array e.g.
http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2
Such a situation defeats the effective functionality of the AUR.

What about stopping this stupid discussion here, and instead discussing the real technical problems we have?
I was wondering if a restricted bash shell would make sourcing PKGBUILDs safer for AUR.
If there is really no way to make it safer, another question would be whether AUR interpreter can be improved/extended, and to which extents.
If you have nothing to add to these concerns, please just stop here, you already repeated your points 10 times in two different bug reports, we all got it.

I do apologize if I upset you with my comments. I honestly thought that there would be space for clarification.

Okay, now I understand that the PKGBUILD definition should only read "whatever does not break makepkg", good, that's already more than it was said before. Tell me which part of the PKGBUILD man page said this before?
All I could see there (if you pointed out one other part already)
###
The following is a list of standard options and directives available for use in a PKGBUILD. These are all understood and interpreted by makepkg, and most will be directly transferred to the built package.
###
For me this said, that these and only these functions should be used. So you say that this is not true - then let people know! No, I never thought AUR is right, otherwise I wouldn't try to improve it.... But tell me, how can a code conform to something, that is not defined???

I want to talk about real technical issues - that's what I'm trying to figure out. AUR does not need bash shell to source PKGBUILDS - it only has to UNDERSTAND the package format. If that's stupid, I don't know how do you imagine any code to be improved.
Best wishes....