| 1 |
On Mon, 23 Jul 2012 20:29:44 +0800 |
| 2 |
Ben de Groot <yngwin@g.o> wrote: |
| 3 |
|
| 4 |
> >> # ones. This function is normally used internally in this eclass, |
| 5 |
> >> not by # l10n.eclass consumers. |
| 6 |
> >> l10n_get_locales() { |
| 7 |
> > |
| 8 |
> > I'd mark this function @INTERNAL then, at least until someone can |
| 9 |
> > presents a use case. |
| 10 |
> > If you are sufficiently sure this function shouldn't be used by |
| 11 |
> > consumers you could remove the function |
| 12 |
> |
| 13 |
> There are use cases, e.g. net-im/qtwitter-0.10.0-r1 for which I have |
| 14 |
> an editted -r10 revision in my dev overlay. I'm sure it could be |
| 15 |
> handled with l10n_for_each_locale_do, but the migration is more |
| 16 |
> straight-forward by simply using l10n_get_locales in this case. |
| 17 |
> |
| 18 |
> This is why I worded it "normally" instead of "only". Maybe the |
| 19 |
> wording could be improved? |
| 20 |
|
| 21 |
The primary concern should be expressiveness. That said, qttwitter |
| 22 |
looks like a good example use case. You have convinced me. |
| 23 |
|
| 24 |
src_configure() { |
| 25 |
qmake4 PREFIX="/usr" LANGS="$(l10n_get_locales)" |
| 26 |
} |
| 27 |
|
| 28 |
Maybe l10n_get_enabled_locales would read even more natural here? |
| 29 |
|
| 30 |
Either way I'd drop the internal entirely as it also provides a simple |
| 31 |
way to "sanitize" LINGUAS without relying on the package manager. ie. |
| 32 |
setting 'LINGUAS="$(l10n_get_locales)"' in an ebuild would enable the |
| 33 |
possible EAPI 5 behaviour described later in this thread, which would |
| 34 |
allow direct use of LINGUAS. The only difference being the backup |
| 35 |
locale. |
Archives