Translation: Add es-mx dialect translation

[javier-squid]

es-mx.po translation file

[squid-prbot]

Can one of the admins verify this patch?

[yadij]

OK to test

[yadij]

File contents look okay now. You will need to update the errors/aliases file entry to prevent directory and symlink collision on binary install.

[yadij]

Approving now under 10-day criteria. Will do the integration parts myself as a followup PR shortly.

[moracca]

@yadij you mentioned "You will need to update the errors/aliases file entry to prevent directory and symlink collision on binary install."

Do you know if this ever happened? We are getting failures when upgrading from 4.x to 5.x where it fails while renaming files in this directory. I finally tracked it down by running truss to determine that the files were being extracted to the old symlinked directory before the symlink directory gets replaced with a real folder, causing the following error during upgrade:

Installed packages to be UPGRADED:

	squid: 4.15 -> 5.6 [local]

Number of packages to be upgraded: 1

Proceed with this action? [y/N]: y

[1/1] Upgrading squid from 4.15 to 5.6...
===> Creating groups.
Using existing group 'squid'.
===> Creating users
Using existing user 'squid'.
===> Creating homedir(s)
===> Pre-installation configuration for squid-5.6
[1/1] Extracting squid-5.6: 100%

pkg: Fail to rename /usr/local/etc/squid/errors/es-mx/.pkgtemp.ERR_ACCESS_DENIED.Vb543SO8sSxC -> /usr/local/etc/squid/errors/es-mx/ERR_ACCESS_DENIED:No such file or directory

I was only able to work around this problem by deleting the symlink before trying pkg upgrade.

Could this fix be added to an upcoming release?

[moracca]

On second thought, I DO see es-mx in the errors/aliases file (commit), so it looks like that part was done, but perhaps there is still an issue when upgrading from a version where it used to be symlinked but now has its own locale?

[yadij]

@moracca, ouch, the fix for this will have to be done by the package vendor - to ensure the old alias symlinks are updated/removed before the new package contents are installed. Our script does not do that in order to avoid removing admins custom symlinks.

[yadij]

UPDATE: actually no that was wrong. The symlinks are created by our automake. I think I can/should fix it here.