1 |
Hi. |
2 |
|
3 |
We have LINGUAS support in portage for quite some time now, but how do |
4 |
we handle LINGUAS? It's not as evident as it seems and thus we need some |
5 |
guidelines. So I'll formulate few questions below but first let's look |
6 |
how portage works with LINGUAS. If you know this skip to Questions |
7 |
section below. |
8 |
|
9 |
|
10 |
Portage/gettext |
11 |
--------------- |
12 |
|
13 |
Like USE variable LINGUAS value could be set by user in /etc/make.conf, |
14 |
package.keywords or environment. There are three different cases: 1) |
15 |
LINGUAS set to some value, 2) LINGUAS set and contains '*'[1] 3) LINGUAS |
16 |
unset. portage will treat this cases differently for ebuilds with |
17 |
linguas_<lang> in IUSE and without. This makes 6 cases: |
18 |
|
19 |
1. In case LINGUAS is set and ebuild has no linguas_<lang> in IUSE |
20 |
portage exports LINGUAS as is. |
21 |
|
22 |
2. In case LINGUAS is set and IUSE contains linguas_<lang> portage |
23 |
exports intersection of languages in LINGUAS and IUSE. E.g. LINGUAS set |
24 |
to "lang1 lang2" and IUSE contains "linguaus_<lang1> linguaus_<lang3>" |
25 |
portage will export LINGUAS="lang1". |
26 |
|
27 |
3. In case LINGUAS contains '*' and there is no linguaus_<lang> in IUSE |
28 |
portage unsets LINGUAS. |
29 |
|
30 |
4. In case LINGUAS contains '*' and IUSE contains linguas_<lang> portage |
31 |
exports LINGUAS with langs defined in the IUSE's linguas_<lang>. |
32 |
|
33 |
5. If LINGUAS is unset and ebuild has no linguas_<lang> flag portage |
34 |
unsets LINGUAS. |
35 |
|
36 |
6. In case LINGUAS is unset and IUSE contains linguas_<lang> portage |
37 |
exports LINGUAS="". |
38 |
|
39 |
| ebuild contains linguas_<lang> the IUSE | |
40 |
--------------------------------------------------| |
41 |
| no | yes | |
42 |
------------------------------------------------------------------- |
43 |
LINGUAS unset | LINGUAS unset | LINGUAS='' | |
44 |
------------------------------------------------------------------| |
45 |
LINGUAS has '*' | LINGUAS unset | LINGUAS='lang' | |
46 |
------------------------------------------------------------------- |
47 |
LINGUAS set |LINGUAS set literally|LINGUAS set to intersection| |
48 |
| |of lang in IUSE and LINGUAS| |
49 |
------------------------------------------------------------------- |
50 |
|
51 |
BTW, I guess all above is applicable to all USE_EXPANDED variables. |
52 |
|
53 |
But unlike other variables LINGUAS is used by gettext and in case it is |
54 |
unset gettext installs all translations. |
55 |
|
56 |
|
57 |
Questions |
58 |
--------- |
59 |
|
60 |
1. Do we want all packages to support LINGUAS if possible? It is |
61 |
possible to leave gettext based package without LINGUAS and everything |
62 |
will just work, but I think that it's good idea to make supported |
63 |
languages visible to user through linguas_<lang> flags. |
64 |
|
65 |
2. How should we handle case of unset LINGUAS in ebuild? Should we mimic |
66 |
gettext and install all supported languages, using code like |
67 |
|
68 |
LINGUAS=${LINGUAS-%UNSET%} |
69 |
if test "%UNSET%" == "$LINGUAS"; then |
70 |
# install all supported languages |
71 |
fi |
72 |
|
73 |
? If yes, it's easy to write such code and put in eclass. If no, how do |
74 |
we live with inconsistency that some packages will install all languages |
75 |
some, will install nothing (document in handbook and add portage warning |
76 |
in case LINGUAS is unset?)? |
77 |
|
78 |
3. What is the purpose of strip-linguas function (mentioned in |
79 |
devmanual)? It's clear what it does but I have no ideas why. Probably |
80 |
similar code could be used in QA function that will gather supported |
81 |
languages from po directories and warn maintainer that it's time to |
82 |
update linguas_<lang> in IUSE (and probably later it could be expanded |
83 |
to support qt packages too). |
84 |
|
85 |
|
86 |
|
87 |
[1] or equivalently linguas_* is set in package.use |
88 |
|
89 |
-- |
90 |
Peter. |