1 |
Hello all, |
2 |
|
3 |
I'm packaging a handful of dictionaries for various languages; some |
4 |
of them have non-ASCII names in English. Example: |
5 |
``` |
6 |
DESCRIPTION="Giellatekno morphological dictionaries for Apurinã." |
7 |
|
8 |
``` |
9 |
|
10 |
Repoman complains: |
11 |
``` |
12 |
variable.invalidchar [fatal] 5 |
13 |
app-dicts/giella-apu/giella-apu-9999.ebuild: DESCRIPTION variable |
14 |
contains non-ASCII character at position 50 |
15 |
``` |
16 |
|
17 |
A brief discussion in #gentoo-dev-help found GLEP 31: |
18 |
|
19 |
> <tastytea> Only ASCII is permitted in code which is parsed by bash |
20 |
> and output: |
21 |
> <https://www.gentoo.org/glep/glep-0031.html#ebuild-and-eclass-character-sets>. |
22 |
|
23 |
From GLEP31: |
24 |
> Ebuild and Eclass Character Sets |
25 |
> |
26 |
> For the same reasons as previously, it is proposed that UTF-8 is |
27 |
> used as the official encoding for ebuild and eclass files. |
28 |
> |
29 |
> However, developers should be warned that any code which is parsed |
30 |
> by bash (in other words, non-comments), and any output which is |
31 |
> echoed to the screen (for example, einfo messages) or given to |
32 |
> portage (for example any of the standard global variables) must not |
33 |
> use anything outside the regular ASCII 0..127 range for |
34 |
> compatibility purposes. |
35 |
|
36 |
What does "compatibility purposes" mean here? Non-unicode locales and |
37 |
terminal state corruption? Other tools? |
38 |
|
39 |
I would like the ebuild short description to refer to these languages |
40 |
by their names, instead of by e.g. ISO-639-3 codes. |
41 |
|
42 |
Thoughts? |
43 |
|
44 |
Cheers, |
45 |
Nick |