Re: LC_CTYPE for spanish speaking countries
On Mon, May 13, 2013 at 06:02:22AM -0500, Vladimir Támara Patiño wrote: > > On Mon, May 13, 2013 at 09:16:39AM +0100, Stuart Henderson wrote: > >Please send unified diffs, the default diff format is very hard to read > > > >echo diff -uNp >> ~/.cvsrc > > > > Sorry and thank you, attached is unified > Index: Makefile > === > RCS file: /cvs/src/share/locale/ctype/Makefile,v > retrieving revision 1.6 > diff -u -p -r1.6 Makefile > --- Makefile 16 Jul 2011 21:33:30 - 1.6 > +++ Makefile 13 May 2013 11:00:16 - > @@ -80,14 +80,15 @@ LOCALES += en_US.ISO8859-15 > +LOCALES_ES = es_AR es_BO es_CH es_CO es_CR es_CU es_DO es_EC es_ES es_GQ > es_GT es_HN es_MX es_NI es_PA es_PE es_PR es_PY es_SV es_US es_UY es_VE This mailing list thread is about adding more locales for spanish speaking countries. The proposed symlink changes should go to a different thread than this one. Adding these locales is an unrelated change to making more use of symlinks in /usr/share/locale. Please don't mix unrelated changes together -- start a new diff and mailing list thread instead. Not doing so complicates review and discussion of the changes, and means that committers might need to tweak your diffs before commit. Which makes your diffs less likely to be committed because it is more work on behalf of the committer. And having tweaked your diffs a committer cannot just say "patch by: you".
Re: LC_CTYPE for spanish speaking countries
On Mon, May 13, 2013 at 09:16:39AM +0100, Stuart Henderson wrote:
Please send unified diffs, the default diff format is very hard to read
echo diff -uNp >> ~/.cvsrc
Sorry and thank you, attached is unified
--
Dios, gracias por tu amor infinito.
--
Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/
http://www.pasosdejesus.org/dominio_publico_colombia.html
Index: Makefile
===
RCS file: /cvs/src/share/locale/ctype/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile16 Jul 2011 21:33:30 - 1.6
+++ Makefile13 May 2013 11:00:16 -
@@ -80,14 +80,15 @@ LOCALES += en_US.ISO8859-15
LOCALES += en_US.UTF-8
LOCALESRC_en_US.UTF-8 = en_US.UTF-8
-LOCALES += es_ES.ISO8859-1
- LOCALESRC_es_ES.ISO8859-1 = en_US.ISO_8859-1
-
-LOCALES += es_ES.ISO8859-15
- LOCALESRC_es_ES.ISO8859-15 = en_US.DIS_8859-15
-
-LOCALES += es_ES.UTF-8
- LOCALESRC_es_ES.UTF-8 = en_US.UTF-8
+LOCALES_ES = es_AR es_BO es_CH es_CO es_CR es_CU es_DO es_EC es_ES es_GQ es_GT
es_HN es_MX es_NI es_PA es_PE es_PR es_PY es_SV es_US es_UY es_VE
+.for c in ${LOCALES_ES}
+LOCALES += ${c}.ISO8859-1
+ LOCALESRC_${c}.ISO8859-1 = en_US.ISO_8859-1
+LOCALES += ${c}.ISO8859-15
+ LOCALESRC_${c}.ISO8859-15 = en_US.DIS_8859-15
+LOCALES += ${c}.UTF-8
+ LOCALESRC_${c}.UTF-8 = en_US.UTF-8
+.endfor
LOCALES += fa_IR.UTF-8
LOCALESRC_fa_IR.UTF-8 = en_US.UTF-8
@@ -293,7 +294,6 @@ LOCALESRCS+=${LOCALESRC_${locale}}
.endfor
CLEANFILES+= ${LOCALES:S/$/.out/g}
-# TODO: more use of symlinks?
FILES= ${LOCALES:S/$/.out/g}
.for locale in ${LOCALES}
FILESDIR_${locale}.out=${LOCALEDIR}/${locale}
@@ -304,14 +304,21 @@ install:
.for locale in ${LOCALES}
install -o ${LOCALEOWN} -g ${LOCALEGRP} -m ${DIRMODE} -d \
${DESTDIR}${LOCALEDIR}/${locale}
- install -o ${LOCALEOWN} -g ${LOCALEGRP} -m ${LOCALEMODE} \
- ${locale}.out ${DESTDIR}${LOCALEDIR}/${locale}/LC_CTYPE
+ if (test "${LOCALESRC_${locale}:S/ISO_/ISO/g:S/DIS_/ISO/g}" !=
"${locale}") then { \
+ ln -fs
../${LOCALESRC_${locale}:S/ISO_/ISO/g:S/DIS_/ISO/g}/LC_CTYPE
${DESTDIR}${LOCALEDIR}/${locale}/LC_CTYPE; \
+ } else { \
+ install -o ${LOCALEOWN} -g ${LOCALEGRP} -m ${LOCALEMODE} \
+ ${locale}.out ${DESTDIR}${LOCALEDIR}/${locale}/LC_CTYPE; \
+ } fi;
+
.endfor
.for locale in ${LOCALES}
${locale}.out: ${LOCALESRC_${locale}}.src
- ${CPP} -I${.CURDIR} < ${.CURDIR}/${LOCALESRC_${locale}}.src | \
- sed -e '/^#/d' | mklocale -o ${.TARGET}
+ if (test "${LOCALESRC_${locale}:S/ISO_/ISO/g:S/DIS_/ISO/g}" =
"${locale}") then { \
+ ${CPP} -I${.CURDIR} <
${.CURDIR}/${LOCALESRC_${locale}:S/ISO_/ISO/g:S/DIS_/ISO/g}.src | \
+ sed -e '/^#/d' | mklocale -o ${.TARGET}; \
+ } fi;
.endfor
.SUFFIXES: .src .out
Re: LC_CTYPE for spanish speaking countries
Please send unified diffs, the default diff format is very hard to read
echo diff -uNp >> ~/.cvsrc
On 2013/05/12 18:57, Vladimir Támara Patiño wrote:
>
> After private conversation with Stefan I'm sending patch that uses links
> in /usr/share/locale for LC_CTYPE instead of copying (by the way
> there was a commentary in /usr/src/share/locale/ctype/Makefile
> suggesting using
> symlinks!).
> Besides this patch adds locales for spanish speaking countries.
>
> This method reduces the size of /usr/shar/locale from 2.1M to 556K
> (even with new locales for all spanish speaking countries).
>
> The same can be done with LC_COLLATE (after having collation
> support).
>
> Best regards.
> --
> Dios, gracias por tu amor infinito.
> -- Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/
> http://www.pasosdejesus.org/dominio_publico_colombia.html
>
> ? m
> ? obj
> Index: Makefile
> ===
> RCS file: /cvs/src/share/locale/ctype/Makefile,v
> retrieving revision 1.6
> diff -r1.6 Makefile
> 83,90c83,91
> < LOCALES += es_ES.ISO8859-1
> < LOCALESRC_es_ES.ISO8859-1 = en_US.ISO_8859-1
> <
> < LOCALES += es_ES.ISO8859-15
> < LOCALESRC_es_ES.ISO8859-15 = en_US.DIS_8859-15
> <
> < LOCALES += es_ES.UTF-8
> < LOCALESRC_es_ES.UTF-8 = en_US.UTF-8
> ---
> > LOCALES_ES = es_AR es_BO es_CH es_CO es_CR es_CU es_DO es_EC es_ES es_GQ
> > es_GT es_HN es_MX es_NI es_PA es_PE es_PR es_PY es_SV es_US es_UY es_VE
> > .for c in ${LOCALES_ES}
> > LOCALES += ${c}.ISO8859-1
> > LOCALESRC_${c}.ISO8859-1 = en_US.ISO_8859-1
> > LOCALES += ${c}.ISO8859-15
> > LOCALESRC_${c}.ISO8859-15 = en_US.DIS_8859-15
> > LOCALES += ${c}.UTF-8
> > LOCALESRC_${c}.UTF-8 = en_US.UTF-8
> > .endfor
> 296d296
> < # TODO: more use of symlinks?
> 307,308c307,313
> < install -o ${LOCALEOWN} -g ${LOCALEGRP} -m ${LOCALEMODE} \
> < ${locale}.out ${DESTDIR}${LOCALEDIR}/${locale}/LC_CTYPE
> ---
> > if (test "${LOCALESRC_${locale}:S/ISO_/ISO/g:S/DIS_/ISO/g}" !=
> > "${locale}") then { \
> > ln -fs
> > ../${LOCALESRC_${locale}:S/ISO_/ISO/g:S/DIS_/ISO/g}/LC_CTYPE
> > ${DESTDIR}${LOCALEDIR}/${locale}/LC_CTYPE; \
> > } else { \
> > install -o ${LOCALEOWN} -g ${LOCALEGRP} -m ${LOCALEMODE} \
> > ${locale}.out ${DESTDIR}${LOCALEDIR}/${locale}/LC_CTYPE; \
> > } fi;
> >
> 313,314c318,321
> < ${CPP} -I${.CURDIR} < ${.CURDIR}/${LOCALESRC_${locale}}.src | \
> < sed -e '/^#/d' | mklocale -o ${.TARGET}
> ---
> > if (test "${LOCALESRC_${locale}:S/ISO_/ISO/g:S/DIS_/ISO/g}" =
> > "${locale}") then { \
> > ${CPP} -I${.CURDIR} <
> > ${.CURDIR}/${LOCALESRC_${locale}:S/ISO_/ISO/g:S/DIS_/ISO/g}.src | \
> > sed -e '/^#/d' | mklocale -o ${.TARGET}; \
> > } fi;
Re: LC_CTYPE for spanish speaking countries
After private conversation with Stefan I'm sending patch that uses links
in /usr/share/locale for LC_CTYPE instead of copying (by the way there was a
commentary in /usr/src/share/locale/ctype/Makefile suggesting using
symlinks!).
Besides this patch adds locales for spanish speaking countries.
This method reduces the size of /usr/shar/locale from 2.1M to 556K (even
with new locales for all spanish speaking countries).
The same can be done with LC_COLLATE (after having collation support).
Best regards.
--
Dios, gracias por tu amor infinito.
--
Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/
http://www.pasosdejesus.org/dominio_publico_colombia.html
? m
? obj
Index: Makefile
===
RCS file: /cvs/src/share/locale/ctype/Makefile,v
retrieving revision 1.6
diff -r1.6 Makefile
83,90c83,91
< LOCALES += es_ES.ISO8859-1
< LOCALESRC_es_ES.ISO8859-1 = en_US.ISO_8859-1
<
< LOCALES += es_ES.ISO8859-15
< LOCALESRC_es_ES.ISO8859-15 = en_US.DIS_8859-15
<
< LOCALES += es_ES.UTF-8
< LOCALESRC_es_ES.UTF-8 = en_US.UTF-8
---
> LOCALES_ES = es_AR es_BO es_CH es_CO es_CR es_CU es_DO es_EC es_ES es_GQ
> es_GT es_HN es_MX es_NI es_PA es_PE es_PR es_PY es_SV es_US es_UY es_VE
> .for c in ${LOCALES_ES}
> LOCALES += ${c}.ISO8859-1
> LOCALESRC_${c}.ISO8859-1 = en_US.ISO_8859-1
> LOCALES += ${c}.ISO8859-15
> LOCALESRC_${c}.ISO8859-15 = en_US.DIS_8859-15
> LOCALES += ${c}.UTF-8
> LOCALESRC_${c}.UTF-8 = en_US.UTF-8
> .endfor
296d296
< # TODO: more use of symlinks?
307,308c307,313
< install -o ${LOCALEOWN} -g ${LOCALEGRP} -m ${LOCALEMODE} \
< ${locale}.out ${DESTDIR}${LOCALEDIR}/${locale}/LC_CTYPE
---
> if (test "${LOCALESRC_${locale}:S/ISO_/ISO/g:S/DIS_/ISO/g}" !=
> "${locale}") then { \
> ln -fs
> ../${LOCALESRC_${locale}:S/ISO_/ISO/g:S/DIS_/ISO/g}/LC_CTYPE
> ${DESTDIR}${LOCALEDIR}/${locale}/LC_CTYPE; \
> } else { \
> install -o ${LOCALEOWN} -g ${LOCALEGRP} -m ${LOCALEMODE} \
> ${locale}.out ${DESTDIR}${LOCALEDIR}/${locale}/LC_CTYPE; \
> } fi;
>
313,314c318,321
< ${CPP} -I${.CURDIR} < ${.CURDIR}/${LOCALESRC_${locale}}.src | \
< sed -e '/^#/d' | mklocale -o ${.TARGET}
---
> if (test "${LOCALESRC_${locale}:S/ISO_/ISO/g:S/DIS_/ISO/g}" =
> "${locale}") then { \
> ${CPP} -I${.CURDIR} <
> ${.CURDIR}/${LOCALESRC_${locale}:S/ISO_/ISO/g:S/DIS_/ISO/g}.src | \
> sed -e '/^#/d' | mklocale -o ${.TARGET}; \
> } fi;
Re: LC_CTYPE for spanish speaking countries
On Fri, Mar 22, 2013 at 12:29:19PM +0100, Stefan Sperling wrote: > On Fri, Mar 22, 2013 at 09:55:01AM +, Creamy wrote: > > Are you suggesting to add individual locales as and when a significant > > number of translations exist in ports, (good idea), or to select a > > few South-American dialects to represent the whole continent, (very > > bad idea)? > > A mix of the two. I don't want to make technical decisions based > on politics. Agreed. > I'd like to recognize and fix situations where people > are missing functionality from the system because their language > of choice is not represented properly. It's not a black and white > decision, it's a trade-off. Agreed - as pointed out in a previous message in this thread, for the time being, more benefit would come from improving es_ES. Any Spanish speaker who doesn't understand English would benefit significantly from this, and in any case, they are in the best position to provide us with a further translation for their local dialect. > Also, I think that extending the locale implementation (such as > adding support for LC_TIME, LC_COLLATE, etc) is much more important > at this stage than adding additional files to /usr/share/locale. Yes. > > There is often more difference between South-American dialects of > > Spanish than between any one of them and Castillian Spanish. How would > > you decide which country is going to represent the whole of the continent? > > That's a tough question, and I really don't mean to alienate people > who speak any of these dialects. But I'd like to avoid the situation > where typing the name of a locale is something that people associate > with their own identity. Because then, there would be no reason at > all to stop adding more locales until the /usr filesystem is full. I strongly agree here... > Systems like Debian ask their users to generate some selection of > locales during the installation process. I don't think it is a good > idea to ask users to make that kind of choice during system installation. > But it's a consequence of the fact that Debian has too many locales. ... and here ... > > > No offence, but to me, the name of a locale is just... a name. > > > Let's try to make useful functional changes to the system. > > > Adding locales for purely patriotic reasons seems like a waste of time > > > to me. > > > > I agree, especially as there will always be awkward individuals like me > > who live in one country, but speak mostly foreign languages, and use > > date formats and keyboard layouts which don't correspond to any standard > > locale either for the country they reside in, or the foreign languages > > they speak. > > Exactly. I'm a native speaker of German, but learned a significant > amount of English in Ireland during my teenage years forcing me to > slowly recover some chunks of my memory of German when I got back. > All my computers speak English to me and I speak English to them, > whether or not people around me speak German to me. I type on a US > keyboard (cannot type on German ones for the life of me), and prefer > to read dates with days given before months because that is what I'm > used to. > > My preferred personal locale would probably be called something > like en_IE_de_DE_kbd_US.UTF-8. ... for that exact reason! I think that there are broadly two types of people who are interested in internationalisation - those who are monolingual and only speak a language other than English, and those who work in mixed environments on a regular basis. Each group will have different views on what is a priority and what isn't. If you have ever been asked to type Spanish on a badly configured Japanese keyboard, on an old version of Windows NT which doesn't allow any real customisation of the keymap, you will understand. (Amasingly, typing Japanese on the keyboard was easy, despite it being mis-configured, as it was handled by a proprietary userland application). > > It only makes sense to add them if there is a real intention to use > > them. Why not just add individual locales as and when a significant number > > of translations exist in ports, as it gives people an incentive to translate > > in to their local language. > > I'd like to avoid making up a set of rules about when new locales can be > added. I think we should discuss this on a case-by-case basis, and allow > people who are genuinely missing functionality to make their case. Sure, but obviously the existance of a large number of translations adds weight to their case. -- Creamy
Re: LC_CTYPE for spanish speaking countries
On Fri, Mar 22, 2013 at 7:12 AM, Stefan Sperling wrote: > On Fri, Mar 22, 2013 at 06:54:24AM -0430, Andres Perera wrote: >> Instead of perpetuating the idea that the number of locales is a >> precious resource tied to directory entries, the routines could parse >> the user supplied string instead of working with a table of all >> possible permutations of ll_CC.CTYPE. This means simplification for >> the build system, simplification for those reasoning about what the >> structure representing a locale should look like, and it also adds >> features without calling for a cliche, tower of babel discussion. >> >> Every field enclosed in brackets denotes the parameter(s) to the LC_ >> function on the LHS: >> >> LC_COLLATE=[ll]_CC.[CTYPE] >> LC_CTYPE=ll_CC.[CTYPE] >> LC_MONETARY=ll_[CC].CTYPE >> LC_NUMERIC=ll_[CC].CTYPE >> LC_TIME=ll_[CC].CTYPE >> LC_MESSAGES=[ll]_[CC].CTYPE >> >> That means that they can be indices to separate flat tables. > > Where is your patch series that implements this in a backwards-compatible > fashion, in small steps that get us from here to there? > > I like the idea of uncoupling locales names from the /usr filesystem a lot. Well, that's just the incentive I needed! > But if it is just an idea it is not as tangible as the patches that Vladimir > is submitting, so it isn't something I can afford to pay attention to > during the limited amount of time I have for OpenBSD development. > As you've picked up on, I have nothing to show for now... hopefully my changes won't interfere.
Re: LC_CTYPE for spanish speaking countries
On Fri, Mar 22, 2013 at 06:54:24AM -0430, Andres Perera wrote: > Instead of perpetuating the idea that the number of locales is a > precious resource tied to directory entries, the routines could parse > the user supplied string instead of working with a table of all > possible permutations of ll_CC.CTYPE. This means simplification for > the build system, simplification for those reasoning about what the > structure representing a locale should look like, and it also adds > features without calling for a cliche, tower of babel discussion. > > Every field enclosed in brackets denotes the parameter(s) to the LC_ > function on the LHS: > > LC_COLLATE=[ll]_CC.[CTYPE] > LC_CTYPE=ll_CC.[CTYPE] > LC_MONETARY=ll_[CC].CTYPE > LC_NUMERIC=ll_[CC].CTYPE > LC_TIME=ll_[CC].CTYPE > LC_MESSAGES=[ll]_[CC].CTYPE > > That means that they can be indices to separate flat tables. Where is your patch series that implements this in a backwards-compatible fashion, in small steps that get us from here to there? I like the idea of uncoupling locales names from the /usr filesystem a lot. But if it is just an idea it is not as tangible as the patches that Vladimir is submitting, so it isn't something I can afford to pay attention to during the limited amount of time I have for OpenBSD development.
Re: LC_CTYPE for spanish speaking countries
On Fri, Mar 22, 2013 at 09:55:01AM +, Creamy wrote: > Are you suggesting to add individual locales as and when a significant > number of translations exist in ports, (good idea), or to select a > few South-American dialects to represent the whole continent, (very > bad idea)? A mix of the two. I don't want to make technical decisions based on politics. I'd like to recognize and fix situations where people are missing functionality from the system because their language of choice is not represented properly. It's not a black and white decision, it's a trade-off. Also, I think that extending the locale implementation (such as adding support for LC_TIME, LC_COLLATE, etc) is much more important at this stage than adding additional files to /usr/share/locale. > There is often more difference between South-American dialects of > Spanish than between any one of them and Castillian Spanish. How would > you decide which country is going to represent the whole of the continent? That's a tough question, and I really don't mean to alienate people who speak any of these dialects. But I'd like to avoid the situation where typing the name of a locale is something that people associate with their own identity. Because then, there would be no reason at all to stop adding more locales until the /usr filesystem is full. Systems like Debian ask their users to generate some selection of locales during the installation process. I don't think it is a good idea to ask users to make that kind of choice during system installation. But it's a consequence of the fact that Debian has too many locales. > > No offence, but to me, the name of a locale is just... a name. > > Let's try to make useful functional changes to the system. > > Adding locales for purely patriotic reasons seems like a waste of time > > to me. > > I agree, especially as there will always be awkward individuals like me > who live in one country, but speak mostly foreign languages, and use > date formats and keyboard layouts which don't correspond to any standard > locale either for the country they reside in, or the foreign languages > they speak. Exactly. I'm a native speaker of German, but learned a significant amount of English in Ireland during my teenage years forcing me to slowly recover some chunks of my memory of German when I got back. All my computers speak English to me and I speak English to them, whether or not people around me speak German to me. I type on a US keyboard (cannot type on German ones for the life of me), and prefer to read dates with days given before months because that is what I'm used to. My preferred personal locale would probably be called something like en_IE_de_DE_kbd_US.UTF-8. > It only makes sense to add them if there is a real intention to use > them. Why not just add individual locales as and when a significant number > of translations exist in ports, as it gives people an incentive to translate > in to their local language. I'd like to avoid making up a set of rules about when new locales can be added. I think we should discuss this on a case-by-case basis, and allow people who are genuinely missing functionality to make their case.
Re: LC_CTYPE for spanish speaking countries
Instead of perpetuating the idea that the number of locales is a precious resource tied to directory entries, the routines could parse the user supplied string instead of working with a table of all possible permutations of ll_CC.CTYPE. This means simplification for the build system, simplification for those reasoning about what the structure representing a locale should look like, and it also adds features without calling for a cliche, tower of babel discussion. Every field enclosed in brackets denotes the parameter(s) to the LC_ function on the LHS: LC_COLLATE=[ll]_CC.[CTYPE] LC_CTYPE=ll_CC.[CTYPE] LC_MONETARY=ll_[CC].CTYPE LC_NUMERIC=ll_[CC].CTYPE LC_TIME=ll_[CC].CTYPE LC_MESSAGES=[ll]_[CC].CTYPE That means that they can be indices to separate flat tables. N.B. POSIX says that locales don't need to map to directories, so why try to fit this into an expanded hierarchical structure when it's clearly not made for it?
Re: LC_CTYPE for spanish speaking countries
On 22/03/13(Fri) 05:08, Abel Abraham Camarillo Ojeda wrote: > On Fri, Mar 22, 2013 at 3:55 AM, Creamy wrote: > > > > There is often more difference between South-American dialects of > > Spanish than between any one of them and Castillian Spanish. How would > > you decide which country is going to represent the whole of the continent? I can imagine your frustration about not being able to set your own variant of the Spanish language, but because we are trying to add new functionalities to the libc, can we please postpone this discussion after collation support is added? Would it be possible to concentrate our efforts on adding support for es_ES first, then talk about the best way/how-to support other Spanish variants? Martin
Re: LC_CTYPE for spanish speaking countries
On Fri, Mar 22, 2013 at 3:55 AM, Creamy wrote: > > There is often more difference between South-American dialects of > Spanish than between any one of them and Castillian Spanish. How would > you decide which country is going to represent the whole of the continent? > +1 > It only makes sense to add them if there is a real intention to use > them. Why not just add individual locales as and when a significant number > of translations exist in ports, as it gives people an incentive to translate > in to their local language. > +1 Just my opinion as a Mexican and spanish speaker.
Re: LC_CTYPE for spanish speaking countries
> I believe we need more than one Spanish locale, because I know that > spoken and written Spanish differs between Europe and South America > in several ways. Unfortunately I don't know any Spanish so I can't > really judge how big these difference are. > > Do we really need _21_ locales for Spanish, like in your diff? > Wouldn't adding one or two locales for South-American dialects of > Spanish be enough to cover these differences, at least where it > makes a difference in terms of OpenBSD's limited functionality, > and where it affects a significant chunk of ports? Are you suggesting to add individual locales as and when a significant number of translations exist in ports, (good idea), or to select a few South-American dialects to represent the whole continent, (very bad idea)? There is often more difference between South-American dialects of Spanish than between any one of them and Castillian Spanish. How would you decide which country is going to represent the whole of the continent? > > Why spanish is treated differently? > > No reason. There was simply nobody so far who was bothered by the lack > of other Spanish locales. You are the first person to complain about > this. That's all. > > > Finally I don't live in Spain but in Colombia, so I should be able to > > use es_CO. How do you translate 'kernel panic' in to Quechua? :-) > No offence, but to me, the name of a locale is just... a name. > Let's try to make useful functional changes to the system. > Adding locales for purely patriotic reasons seems like a waste of time > to me. I agree, especially as there will always be awkward individuals like me who live in one country, but speak mostly foreign languages, and use date formats and keyboard layouts which don't correspond to any standard locale either for the country they reside in, or the foreign languages they speak. It only makes sense to add them if there is a real intention to use them. Why not just add individual locales as and when a significant number of translations exist in ports, as it gives people an incentive to translate in to their local language. -- Creamy
Re: LC_CTYPE for spanish speaking countries
On Thu, Mar 21, 2013 at 06:59:44PM -0500, Vladimir Támara Patiño wrote: > Regarding the situtation with other languages, in > /usr/src/share/locale/ctype/Makefile I find the following languages > with countries pointing all of them to the same cmap definitions: > * de_AT, de_CH and de_DE Taking this as an example, I do think that one German locale would be enough, given that all these language variants use the exact same character sets and written language looks the same everywhere (to me, as a native speaker). There might be other differences, but these don't matter for OpenBSD right now. OpenBSD's locale feature set is so limited that making a distinction between Austria, Switzerland, and Germany really makes no sense. The only locale-specific things in OpenBSD are: - the available character set - message files for programs from ports (base system has very few translations) So, in the case of German, the result of setting any of these de_* locales is the same in practice. I doubt anyone goes through the hassle of maintaining separate translations for 3 German-speaking countries. There will usually be one translation and it gets installed as de_DE, de_AT, and de_CH. On non-OpenBSD systems, people might prefer de_CH over de_DE for other reasons, so it makes sense to provide this locale. But on OpenBSD it doesn't make much sense yet. I believe we need more than one Spanish locale, because I know that spoken and written Spanish differs between Europe and South America in several ways. Unfortunately I don't know any Spanish so I can't really judge how big these difference are. Do we really need _21_ locales for Spanish, like in your diff? Wouldn't adding one or two locales for South-American dialects of Spanish be enough to cover these differences, at least where it makes a difference in terms of OpenBSD's limited functionality, and where it affects a significant chunk of ports? > * fr_BE, fr_CA, fr_CH, fr_FR > * it_CH, it_IT > * nl_BE, nl_NL > > Why spanish is treated differently? No reason. There was simply nobody so far who was bothered by the lack of other Spanish locales. You are the first person to complain about this. That's all. > Finally I don't live in Spain but in Colombia, so I should be able to > use es_CO. No offence, but to me, the name of a locale is just... a name. Let's try to make useful functional changes to the system. Adding locales for purely patriotic reasons seems like a waste of time to me. Please tell me more about the functional reasons you have for adding 21 additional locale files, and why adding less than 21 would not suffice.
Re: LC_CTYPE for spanish speaking countries
Some ports in snapshot that include .po or .mo catalogs different to es_ES are (just listing few without repetition): davical es_AR es_MX es_VE gnomebaker es_CO, es_CR poedit es_PR zarafa es_CA The following packages have other localization files practically for every spanish speaking country (in the list I sent I have to add es_CA and es_US that are already there): concrete5, icinga-web, ocaml-camomile, p5-DateTime-Locale, py-babel, py-turbogears, zendframework Regarding the situtation with other languages, in /usr/src/share/locale/ctype/Makefile I find the following languages with countries pointing all of them to the same cmap definitions: * de_AT, de_CH and de_DE * fr_BE, fr_CA, fr_CH, fr_FR * it_CH, it_IT * nl_BE, nl_NL Why spanish is treated differently? Finally I don't live in Spain but in Colombia, so I should be able to use es_CO. H Best regards. On Thu, Mar 21, 2013 at 01:24:34AM +0100, Stefan Sperling wrote: On Wed, Mar 20, 2013 at 04:50:39PM -0430, Andres Perera wrote: > On Wed, Mar 20, 2013 at 2:50 PM, Stefan Sperling wrote: > > On Tue, Mar 19, 2013 at 06:44:59PM -0500, Vladimir Támara Patiño wrote: > >> +#http://en.wikipedia.org/wiki/List_of_countries_where_Spanish_is_an_official_language > >> +ES_COUNTRIES= AR BO CH CO CR CU DO EC ES GQ GT HN MX NI PA PE PR PY SV UY VE > > > > Sorry, but I don't really see the point of this. > > > > All these names are going to map to the same ctype definitions. > > That just clutters the /usr/share/locale directory. Why can't people > > just use es_ES? > > Because that's wrong. es_VE for ctype alone won't make a difference, > but BSF isn't the same as Euro, is it? (hah) Date formats, etc., are > different. And dictionary files (e.g., spellings for common cities) > are also different. Yes, but unfortunately OpenBSD's locale implemnentation doesn't yet support much of what you mention above. AFAIK we currently only support the LC_CTYPE locale category. Please show me a real benefit of this change within the current implementation, or extend the implementation to create a benefit. Or you could identify some ports which install message files where adding new spanish locale variants will really make a difference. If such ports exist, I'm happy to add the corresponding locale variants. But I'm not going to bother making no-op changes to the system. -- Dios, gracias por tu amor infinito. -- Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/ http://www.pasosdejesus.org/dominio_publico_colombia.html
Re: LC_CTYPE for spanish speaking countries
On Wed, Mar 20, 2013 at 04:50:39PM -0430, Andres Perera wrote: > On Wed, Mar 20, 2013 at 2:50 PM, Stefan Sperling wrote: > > On Tue, Mar 19, 2013 at 06:44:59PM -0500, Vladimir Támara Patiño wrote: > >> +#http://en.wikipedia.org/wiki/List_of_countries_where_Spanish_is_an_official_language > >> +ES_COUNTRIES= AR BO CH CO CR CU DO EC ES GQ GT HN MX NI PA PE PR PY SV UY > >> VE > > > > Sorry, but I don't really see the point of this. > > > > All these names are going to map to the same ctype definitions. > > That just clutters the /usr/share/locale directory. Why can't people > > just use es_ES? > > Because that's wrong. es_VE for ctype alone won't make a difference, > but BSF isn't the same as Euro, is it? (hah) Date formats, etc., are > different. And dictionary files (e.g., spellings for common cities) > are also different. Yes, but unfortunately OpenBSD's locale implemnentation doesn't yet support much of what you mention above. AFAIK we currently only support the LC_CTYPE locale category. Please show me a real benefit of this change within the current implementation, or extend the implementation to create a benefit. Or you could identify some ports which install message files where adding new spanish locale variants will really make a difference. If such ports exist, I'm happy to add the corresponding locale variants. But I'm not going to bother making no-op changes to the system.
Re: LC_CTYPE for spanish speaking countries
On Wed, Mar 20, 2013 at 2:50 PM, Stefan Sperling wrote:
> On Tue, Mar 19, 2013 at 06:44:59PM -0500, Vladimir Támara Patiño wrote:
>> +#http://en.wikipedia.org/wiki/List_of_countries_where_Spanish_is_an_official_language
>> +ES_COUNTRIES= AR BO CH CO CR CU DO EC ES GQ GT HN MX NI PA PE PR PY SV UY VE
>
> Sorry, but I don't really see the point of this.
>
> All these names are going to map to the same ctype definitions.
> That just clutters the /usr/share/locale directory. Why can't people
> just use es_ES?
Because that's wrong. es_VE for ctype alone won't make a difference,
but BSF isn't the same as Euro, is it? (hah) Date formats, etc., are
different. And dictionary files (e.g., spellings for common cities)
are also different.
The way you specify locales, ll_CC.CHARTYPE, where ll is language and
CC is country-code, is unfortunate because it makes unnecesary
duplication for fields where it shouldn't make a difference, like
ctype, but that's just the way it is
>
> I don't think locale names are standardized, so there should be nothing
> that forces us to support a certain set of locale names.
>
>> +ES_ENCODINGS= ISO8859-1 ISO8859-15 UTF-8
>> +.for c in ${ES_COUNTRIES}
>> +LOCALES += es_${c}.UTF-8
>> +LOCALESRC_es_${c}.UTF-8 = en_US.UTF-8
>> +LOCALES += es_${c}.ISO8859-1
>> +LOCALESRC_es_${c}.ISO8859-1 = en_US.ISO_8859-1
>> +LOCALES += es_${c}.ISO8859-15
>> +LOCALESRC_es_${c}.ISO8859-15 = en_US.DIS_8859-15
>> +.endfor
>>
>> LOCALES += fa_IR.UTF-8
>> LOCALESRC_fa_IR.UTF-8 = en_US.UTF-8
>
Re: LC_CTYPE for spanish speaking countries
On Tue, Mar 19, 2013 at 06:44:59PM -0500, Vladimir Támara Patiño wrote:
> +#http://en.wikipedia.org/wiki/List_of_countries_where_Spanish_is_an_official_language
> +ES_COUNTRIES= AR BO CH CO CR CU DO EC ES GQ GT HN MX NI PA PE PR PY SV UY VE
Sorry, but I don't really see the point of this.
All these names are going to map to the same ctype definitions.
That just clutters the /usr/share/locale directory. Why can't people
just use es_ES?
I don't think locale names are standardized, so there should be nothing
that forces us to support a certain set of locale names.
> +ES_ENCODINGS= ISO8859-1 ISO8859-15 UTF-8
> +.for c in ${ES_COUNTRIES}
> +LOCALES += es_${c}.UTF-8
> +LOCALESRC_es_${c}.UTF-8 = en_US.UTF-8
> +LOCALES += es_${c}.ISO8859-1
> +LOCALESRC_es_${c}.ISO8859-1 = en_US.ISO_8859-1
> +LOCALES += es_${c}.ISO8859-15
> +LOCALESRC_es_${c}.ISO8859-15 = en_US.DIS_8859-15
> +.endfor
>
> LOCALES += fa_IR.UTF-8
> LOCALESRC_fa_IR.UTF-8 = en_US.UTF-8
LC_CTYPE for spanish speaking countries
--
Dios, gracias por tu amor infinito.
--
Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/
http://www.pasosdejesus.org/dominio_publico_colombia.html
Index: Makefile
===
RCS file: /cvs/src/share/locale/ctype/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- Makefile16 Jul 2011 21:33:30 - 1.6
+++ Makefile19 Mar 2013 23:39:06 -
@@ -80,14 +80,17 @@
LOCALES += en_US.UTF-8
LOCALESRC_en_US.UTF-8 = en_US.UTF-8
-LOCALES += es_ES.ISO8859-1
- LOCALESRC_es_ES.ISO8859-1 = en_US.ISO_8859-1
-
-LOCALES += es_ES.ISO8859-15
- LOCALESRC_es_ES.ISO8859-15 = en_US.DIS_8859-15
-
-LOCALES += es_ES.UTF-8
- LOCALESRC_es_ES.UTF-8 = en_US.UTF-8
+#http://en.wikipedia.org/wiki/List_of_countries_where_Spanish_is_an_official_language
+ES_COUNTRIES= AR BO CH CO CR CU DO EC ES GQ GT HN MX NI PA PE PR PY SV UY VE
+ES_ENCODINGS= ISO8859-1 ISO8859-15 UTF-8
+.for c in ${ES_COUNTRIES}
+LOCALES += es_${c}.UTF-8
+LOCALESRC_es_${c}.UTF-8 = en_US.UTF-8
+LOCALES += es_${c}.ISO8859-1
+LOCALESRC_es_${c}.ISO8859-1 = en_US.ISO_8859-1
+LOCALES += es_${c}.ISO8859-15
+LOCALESRC_es_${c}.ISO8859-15 = en_US.DIS_8859-15
+.endfor
LOCALES += fa_IR.UTF-8
LOCALESRC_fa_IR.UTF-8 = en_US.UTF-8
