1 |
On K, 2012-02-08 at 11:32 -0500, Mike Gilbert wrote: |
2 |
> I just want to sanity-check my brain here. |
3 |
> |
4 |
> LINGUAS seems to be mainly a variable to control the behavior of |
5 |
> gettext's autoconf code, installed as /usr/share/aclocal/po.m4. |
6 |
> |
7 |
> If LINGUAS is set to a list of language codes, the build system will |
8 |
> only build/install MO files for those languages. If LINGUAS is unset, |
9 |
> the build system will build/install MO files for all available |
10 |
> languages. |
11 |
> |
12 |
> Portage will also use-expand LINGUAS, so an ebuild *can* make use of |
13 |
> it where USE flags are needed. For example, in SRC_URI, where the USE |
14 |
> flags may be used to control downloading of extra language packs. |
15 |
> |
16 |
> Given this information, I come to a few conclusions: |
17 |
> |
18 |
> 1. There is technically no need to define IUSE="linguas_$x" if an |
19 |
> ebuild is not using the USE flags in other ebuild metadata (like |
20 |
> SRC_URI). |
21 |
|
22 |
I'm not sure, but it is not feasible to list them for exposing languages |
23 |
a package has been translated to via gettext/intltool. That's completely |
24 |
unmaintainable and unnecessary. Each version bump could change it, hard |
25 |
and time consuming to validate, etc. |
26 |
|
27 |
> 2. In cases where the USE flags are needed, they should be enabled by |
28 |
> default to emulate the "default-all" behavior of the autoconf macros. |
29 |
> For example: IUSE="+linguas_fr_FR +linguas_de_DE". |
30 |
|
31 |
I would like that, but I don't think any or many packages do so when |
32 |
they use it in SRC_URI |
33 |
|
34 |
> 3. An ebuild could use LINGUAS to control installation of translation |
35 |
> information which does not come from gettext PO files. It does not |
36 |
> necessarily need to make use of the linguas_$x USE flags to do so. |
37 |
|
38 |
One such widely used way is to use intltool, which amongst other things |
39 |
handles PO files as well (of course via gettext tools in the end), but |
40 |
also other things. |
41 |
|
42 |
> Does all of that make sense? |
43 |
> |
44 |
> I am considering simplifying www-client/chromium from the current mess |
45 |
> based on the linguas USE flags to basically just this: |
46 |
> |
47 |
> if [[ ${LINGUAS} ]]; then |
48 |
> for x in *.pak; do |
49 |
> mylang=${x%.pak} |
50 |
> mylang=%{x/-/_} |
51 |
> has $mylang $LINGUAS || rm $x |
52 |
> done |
53 |
> fi |
54 |
|
55 |
It would perhaps be nicer if upstream honored LINGUAS itself too or |
56 |
so... |
57 |
|
58 |
I think users could be surprised a bit about cases where you have |
59 |
variants or dialects, e.g currently as IUSE=linguas_fr_FR, when users |
60 |
only have LINGUAS=fr - in gettext they often don't have a fr_FR.po, just |
61 |
fr.po; if locale has LC_MESSAGE and LANG at fr_FR, it will look at "fr" |
62 |
if more specific fr_FR not found. |
63 |
I define things like LINGUAS="en en_US et et_EE" to be really sure, but |
64 |
I doubt many users do that (but that's just a guess). |
65 |
If it's exposed via IUSE, then they can at least have some visual cue of |
66 |
that. |
67 |
I guess it wouldn't be a concern if we had a tool to set the LINGUAS |
68 |
that handled this variant logic nicely, or just educating users in |
69 |
documentation, make.conf.example comments and so on. |
70 |
|
71 |
> As well, there are probably a few other places in the tree where |
72 |
> conclusion #1 and #2 should be applied. |
73 |
|
74 |
|
75 |
Best, |
76 |
Mart Raudsepp |