The following ebuilds use "me" as a possible value of LINGUAS, which is not listed as a language code in ISO 639-1: www-client/opera-12.16_p1860-r1 www-client/opera-37.0.2178.32 www-client/opera-37.0.2178.43 www-client/opera-beta-37.0.2178.31 www-client/opera-beta-38.0.2220.11 www-client/opera-beta-38.0.2220.12 www-client/opera-developer-39.0.2226.0 www-client/opera-developer-39.0.2234.0 Also, opera-12.16_p1860-r1 has "es_LA" but this is already fixed (replaced by "es_419") in later versions.
LINGUAS=me - When did LINGUAS gain this strict compliance to ISO 639-1 (where I assume various extensions to the standard are included)? LINGUAS=es_LA - That's the exact name of the locale; how do you suppose we fix this? Rename both the file and the USE flag?
(In reply to Jeroen Roovers from comment #1) > LINGUAS=me - When did LINGUAS gain this strict compliance to ISO 639-1 > (where I assume various extensions to the standard are included)? *shrug* Gettext documentation says that the first part should be an ISO 639 code. (Glibc installs a locale for sr_ME, not sure if this code would be appropriate here.) > LINGUAS=es_LA - That's the exact name of the locale; how do you suppose we > fix this? Rename both the file and the USE flag? Probably best if both were renamed to es_419 which would also be consistent with later Opera versions. Alternatively, es_419 could be mapped to the current upstream filename.
Now I see that you have added "me" to l10n.desc, in spite of the file clearly saying "Entries must be valid IETF language tags (BCP 47)." One of the purposes of the transition is to get rid of all the crappy invalid entries previously in linguas.desc, so please either use a valid tag like "sr-ME", or convince the ISO to add "me" as a language tag.
(In reply to Ulrich Müller from comment #3) > Now I see that you have added "me" to l10n.desc, in spite of the file > clearly saying "Entries must be valid IETF language tags (BCP 47)." Yeah, obviously somebody put that in there for mysterious reasons. Sorry to disappoint your expectations of a reality that matches rigid definitions. > One of the purposes of the transition is to get rid of all the crappy > invalid entries previously in linguas.desc, so please either use a valid tag > like "sr-ME", or convince the ISO to add "me" as a language tag. Or you convince Opera to change the label. Or you propose a change to chromium-2.eclass that magically translates one label to the other.
(In reply to Jeroen Roovers from comment #4) > Or you convince Opera to change the label. > Or you propose a change to chromium-2.eclass that magically translates one > label to the other. Third option: Remove "me" from the ebuilds' CHROMIUM_LANGS altogether for now. If any users complain, we can reconsider (or ask them to submit a patch, either upstream or downstream).
commit 9b8a90b4fa52f9cc5eaeeffc3387d8625fa913fe Author: Mike Gilbert <floppym@gentoo.org> Date: Tue Sep 6 21:57:45 2016 -0400 www-client/opera-beta: replace me with sr-ME Bug: https://bugs.gentoo.org/583762 profiles/desc/l10n.desc | 2 +- www-client/opera-beta/opera-beta-40.0.2308.15.ebuild | 4 ++-- www-client/opera-beta/opera-beta-40.0.2308.26.ebuild | 4 ++-- www-client/opera-developer/opera-developer-41.0.2329.0.ebuild | 4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) commit 64f55eacb82928c647e00ef767c909d88a94bbd8 Author: Mike Gilbert <floppym@gentoo.org> Date: Tue Sep 6 21:53:32 2016 -0400 chromium-2.eclass: add special handling for sr-ME Bug: https://bugs.gentoo.org/583762 eclass/chromium-2.eclass | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)
The changes I made should be forward compatible, assuming that 'me' is not added to ISO 639-1 and that Opera upstream eventually changes me.pak to sr-ME.pak. If it goes the other way, some eclass changes will be necessary.
Apparently this is fixed?
Oh, apparently this was fixed where chromium-2.eclass is involved.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a4c59ca35d1c8e916baec83775a60ac7c66c100d commit a4c59ca35d1c8e916baec83775a60ac7c66c100d Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2018-01-06 21:44:53 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2018-01-06 21:48:48 +0000 chromium-2.eclass: drop sr-ME workaround code Closes: https://bugs.gentoo.org/583762 Closes: https://bugs.gentoo.org/643736 eclass/chromium-2.eclass | 16 ++-------------- 1 file changed, 2 insertions(+), 14 deletions(-)
Is there an ETA for removal of opera-12.16_p1860-r1? Otherwise, it should be migrated away from using linguas_* USE flags.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b971baa7f7d66a6dd5e33b3eeecd92678585fc59 commit b971baa7f7d66a6dd5e33b3eeecd92678585fc59 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2018-01-08 19:57:03 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2018-01-08 19:58:21 +0000 www-client/opera: Migrate from LINGUAS to L10N. Map language codes for Montenegrin and Latin American Spanish from their IETF language tags to the codes used by upstream. This change affects only opera-12.16_p1860-r1.ebuild. Closes: https://bugs.gentoo.org/583762 Package-Manager: Portage-2.3.19, Repoman-2.3.6 www-client/opera/opera-12.16_p1860-r1.ebuild | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)
