~alpine/devel

3 2

[alpine-devel] more on language packs

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20110104115326.6b2ea5e0@ncopa-desktop.nor.wtbts.net>
Sender timestamp
1294138406
DKIM signature
missing
Download raw message
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
---
Details
Message ID
<1294473530.617717791@192.168.4.58>
In-Reply-To
<20110104115326.6b2ea5e0@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1294473530
DKIM signature
missing
Download raw message
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
---
Details
Message ID
<1294476657.771325199@192.168.4.58>
In-Reply-To
<4D282065.504@iki.fi> (view parent)
Sender timestamp
1294476657
DKIM signature
missing
Download raw message
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
---
Timo Teräs <timo.teras@iki.fi>
Details
Message ID
<4D282065.504@iki.fi>
In-Reply-To
<1294473530.617717791@192.168.4.58> (view parent)
Sender timestamp
1294475365
DKIM signature
missing
Download raw message
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
---
Reply to thread Export thread (mbox)