1 |
On Fri, 27 May 2016 10:17:20 +0300 |
2 |
Mart Raudsepp <leio@g.o> wrote: |
3 |
|
4 |
> Ühel kenal päeval, L, 21.05.2016 kell 11:19, kirjutas |
5 |
> waltdnes@××××××××.org: |
6 |
> > On Sat, May 21, 2016 at 09:41:28AM +0200, Micha?? Górny wrote |
7 |
> > > 3. We remove LINGUAS from USE_EXPAND and stop using it. If ebuilds |
8 |
> > > have |
9 |
> > > a good reason to use flags for localization, we introduce a new, |
10 |
> > > non-colliding USE_EXPAND for that. We also ask users to replace |
11 |
> > > LINGUAS |
12 |
> > > with the new flag in their make.conf files. LINGUAS gets the |
13 |
> > > original |
14 |
> > > upstream behavior back, and we eventually discourage it in favor of |
15 |
> > > new |
16 |
> > > INSTALL_MASK features (WiP) [2]. |
17 |
> |
18 |
> Short of making an exception to LINGUAS in the USE_EXPAND rules, I |
19 |
> think this is the only way. |
20 |
> |
21 |
> > 5. An reversed variant of INSTALL_MASK in make.conf, e.g. |
22 |
> > LOCALE_ALLOW="foo bar fubar" |
23 |
> > |
24 |
> > 6. Integrate localepurge into Portage, and run it post install |
25 |
> > |
26 |
> > There are some lazy programmers out there who *DO NOT* respect the |
27 |
> > LINGUAS setting, and splatter files throughout /usr/share/locale/* |
28 |
> > and |
29 |
> > /usr/share/man/* regardless. That's the reason "localepurge" was |
30 |
> > written in the first place. Any proposed solution should take that |
31 |
> > problem into consideration, and handle it too. |
32 |
> |
33 |
> For both of these cases, I have to point out that e.g |
34 |
> LINGUAS="en et pl" |
35 |
> does not mean "keep only /usr/share/locale/{en,et,pl}/*", it means have |
36 |
> support for only these languages. This means for example that *.desktop |
37 |
> files will have translations in them only for those language. Same for |
38 |
> dconf schema files. Same for many other things. MO Translation files |
39 |
> and manuals aren't the only thing here, especially with intltool (and |
40 |
> many of these intltool features are now part of gettext proper). |
41 |
> In short, LINGUAS affects the content of files too, not only the |
42 |
> existence of files. See any file in /usr/share/applications/ for |
43 |
> example. |
44 |
|
45 |
Just to be clear, I don't think we care that much about filtering |
46 |
those. I can understand people not wanting to install a dozen |
47 |
translation files because of their potential size, especially when |
48 |
filesystem can't handle small files efficiently. But stripping extra |
49 |
descriptions from .desktop files doesn't seem like a major use case. |
50 |
|
51 |
> I always put "en" as my first in LINGUAS, due to historical abuse of |
52 |
> the first value there, I think e.g mplayer or vlc used to do this. |
53 |
> LINGUAS is an unordered list, but some packages used to took the first |
54 |
> value as meaning the default and switch the UI to that by default, |
55 |
> instead of honoring LC_* variables. |
56 |
|
57 |
That's yet another reason not to extend the abuse of LINGUAS. I don't |
58 |
really see adding another rule to PMS that attempts to enforce this. |
59 |
|
60 |
> Another reason I put "en" there, is |
61 |
> because of IUSE_EXPAND and packages that might not be natively english, |
62 |
> but do have english translations (I think I've seen some french ones |
63 |
> like that :D) |
64 |
> |
65 |
> |
66 |
> And no, localepurge is not capable of stripping these translations out |
67 |
> of existing files. To my knowledge at least. Though it could be |
68 |
> improved to do so in some cases. |
69 |
|
70 |
Well, this is certainly something that can be done. |
71 |
|
72 |
-- |
73 |
Best regards, |
74 |
Michał Górny |
75 |
<http://dev.gentoo.org/~mgorny/> |