Hi,
I have implemented experiemtnal support for language packs in abuild
(only available from git)
The idea is that you in the APKBUILD set a linguas variable, for
example:
linguas="bg ca cs da de el eo es et fr gl hu id it ja ko lt nl pl pt ru
sk sv tr uk zh"
Then will abuild automatically crate the subpackages $pkgname-lang-bg
$pkgname-lang-ca $pkgname-lang-cs... etc. It wil take
"$pkgdir"/usr/share/locale/$lang* so that pt and pt_BR both comes into
$pkgname-lang-pt and en_CA en_GB both goes into $pkgname-lang-en etc.
It will also create a proper install_if.
This will increase the number of packages significantly. I'm not sure
if or how we could group languages together.
Thoughts?
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Tuesday, January 4, 2011 4:53am, "Natanael Copa" <ncopa@alpinelinux.org>
said:
..snip..
> Then will abuild automatically crate the subpackages $pkgname-lang-bg> $pkgname-lang-ca $pkgname-lang-cs... etc. It wil take> "$pkgdir"/usr/share/locale/$lang* so that pt and pt_BR both comes into> $pkgname-lang-pt and en_CA en_GB both goes into $pkgname-lang-en etc.
That sounds good.
> It will also create a proper install_if.
Also nice.
> This will increase the number of packages significantly. I'm not sure> if or how we could group languages together.> > Thoughts?
Perhaps not exactly what you were wanting, but what if we made a
'language-variation' of the use-flags idea, and then hid all installed
language subpackages by default, with an option to view them.
Such as:
USE_LANG="en pt" (in /etc/apk.conf or something?)
Then with apk:
apk version | grep $pkgname #shows only *$pkgname*
apk version --show-lang-subpkg | grep $pkgname #also shows lang subpkgs
(As a side note, would it be doable to implement wildcards into
'apk version' and perhaps other apk subcommands? ie, apk version *php*)
Updating 'USE_LANG' to add or remove languages would also affect
'apk upgrade'; additional languages would be installed, while the ones
that were removed, get uninstalled.
I don't want to force the user to use any use-flags, but if atleast
'USE_LANG' is implemented, we would need to have some sort of default
language, if we do decide to adopt language subpackages. Maybe hardcode
a default of English while allowing the user to override it completely
with 'USE_LANG'?
Matt
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Saturday, January 8, 2011 2:29am, "Timo Teräs" <timo.teras@iki.fi> said:
> On 01/08/2011 09:58 AM, Matt Smith wrote:>> On Tuesday, January 4, 2011 4:53am, "Natanael Copa" <ncopa@alpinelinux.org>>> said:>> ..snip..>>> Then will abuild automatically crate the subpackages $pkgname-lang-bg>>> $pkgname-lang-ca $pkgname-lang-cs... etc. It wil take>>> "$pkgdir"/usr/share/locale/$lang* so that pt and pt_BR both comes into>>> $pkgname-lang-pt and en_CA en_GB both goes into $pkgname-lang-en etc.>>>> That sounds good.>>>>> It will also create a proper install_if.>>>> Also nice.>>>>> This will increase the number of packages significantly. I'm not sure>>> if or how we could group languages together.>>>>>> Thoughts?>>>> Perhaps not exactly what you were wanting, but what if we made a>> 'language-variation' of the use-flags idea, and then hid all installed>> language subpackages by default, with an option to view them.>>>> Such as:>> USE_LANG="en pt" (in /etc/apk.conf or something?)>>>> Then with apk:>> apk version | grep $pkgname #shows only *$pkgname*>> apk version --show-lang-subpkg | grep $pkgname #also shows lang subpkgs> > > I'd prefer not to do this as language specific. I might be OK with> adding a "hidden package", so it won't show in the generic lists unless> given some "--show-hidden". But it should be generic and not "lang> package" thingy. Or possibly it could be package type field, and we> could specify a filter which types to show by default.
Yes, both of those last two options sound fine, but I'm leaning towards
a package-type field, perhaps defaulting to 'all' package types.
>> (As a side note, would it be doable to implement wildcards into>> 'apk version' and perhaps other apk subcommands? ie, apk version *php*)> > Is doable. "apk search" is currently only command accepting wildcards.> apk version would be good too. Perhaps you could file a feature request> on it to redmine?
Yes, I can file a request - thanks!
>> Updating 'USE_LANG' to add or remove languages would also affect>> 'apk upgrade'; additional languages would be installed, while the ones>> that were removed, get uninstalled.>>>> I don't want to force the user to use any use-flags, but if atleast>> 'USE_LANG' is implemented, we would need to have some sort of default>> language, if we do decide to adopt language subpackages. Maybe hardcode>> a default of English while allowing the user to override it completely>> with 'USE_LANG'?> > Or possibly have english as part of the main package.
Perhaps.
> But this is a good point. A package will definitely need at least one> language pack. Do we want to allow removal of English?
What do you guys think?
Matt
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On 01/08/2011 09:58 AM, Matt Smith wrote:
> On Tuesday, January 4, 2011 4:53am, "Natanael Copa" <ncopa@alpinelinux.org>> said:> ..snip..>> Then will abuild automatically crate the subpackages $pkgname-lang-bg>> $pkgname-lang-ca $pkgname-lang-cs... etc. It wil take>> "$pkgdir"/usr/share/locale/$lang* so that pt and pt_BR both comes into>> $pkgname-lang-pt and en_CA en_GB both goes into $pkgname-lang-en etc.> > That sounds good.> >> It will also create a proper install_if.> > Also nice.> >> This will increase the number of packages significantly. I'm not sure>> if or how we could group languages together.>>>> Thoughts?> > Perhaps not exactly what you were wanting, but what if we made a> 'language-variation' of the use-flags idea, and then hid all installed> language subpackages by default, with an option to view them.> > Such as:> USE_LANG="en pt" (in /etc/apk.conf or something?)> > Then with apk:> apk version | grep $pkgname #shows only *$pkgname*> apk version --show-lang-subpkg | grep $pkgname #also shows lang subpkgs
I'd prefer not to do this as language specific. I might be OK with
adding a "hidden package", so it won't show in the generic lists unless
given some "--show-hidden". But it should be generic and not "lang
package" thingy. Or possibly it could be package type field, and we
could specify a filter which types to show by default.
> (As a side note, would it be doable to implement wildcards into> 'apk version' and perhaps other apk subcommands? ie, apk version *php*)
Is doable. "apk search" is currently only command accepting wildcards.
apk version would be good too. Perhaps you could file a feature request
on it to redmine?
> Updating 'USE_LANG' to add or remove languages would also affect> 'apk upgrade'; additional languages would be installed, while the ones> that were removed, get uninstalled.> > I don't want to force the user to use any use-flags, but if atleast> 'USE_LANG' is implemented, we would need to have some sort of default> language, if we do decide to adopt language subpackages. Maybe hardcode> a default of English while allowing the user to override it completely> with 'USE_LANG'?
Or possibly have english as part of the main package.
But this is a good point. A package will definitely need at least one
language pack. Do we want to allow removal of English?
- Timo
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---