Re: LC_CTYPE for spanish speaking countries

2013-05-13 Thread Stuart Henderson
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

2013-05-13 Thread Vladimir Támara Patiño


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

2013-05-13 Thread Stefan Sperling
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

2013-05-12 Thread Vladimir Támara Patiño


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

2013-03-22 Thread Creamy
 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

2013-03-22 Thread Abel Abraham Camarillo Ojeda
On Fri, Mar 22, 2013 at 3:55 AM, Creamy cre...@nocrater.com 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

2013-03-22 Thread Martin Pieuchot
On 22/03/13(Fri) 05:08, Abel Abraham Camarillo Ojeda wrote:
 On Fri, Mar 22, 2013 at 3:55 AM, Creamy cre...@nocrater.com 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

2013-03-22 Thread Andres Perera
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

2013-03-22 Thread Stefan Sperling
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

2013-03-22 Thread Stefan Sperling
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

2013-03-22 Thread Andres Perera
On Fri, Mar 22, 2013 at 7:12 AM, Stefan Sperling s...@openbsd.org 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

2013-03-22 Thread Creamy
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

2013-03-21 Thread Vladimir Támara Patiño
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 s...@openbsd.org 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

2013-03-21 Thread Stefan Sperling
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

2013-03-20 Thread Stefan Sperling
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



Re: LC_CTYPE for spanish speaking countries

2013-03-20 Thread Andres Perera
On Wed, Mar 20, 2013 at 2:50 PM, Stefan Sperling s...@openbsd.org 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

2013-03-20 Thread Stefan Sperling
On Wed, Mar 20, 2013 at 04:50:39PM -0430, Andres Perera wrote:
 On Wed, Mar 20, 2013 at 2:50 PM, Stefan Sperling s...@openbsd.org 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.



LC_CTYPE for spanish speaking countries

2013-03-19 Thread Vladimir Támara Patiño



--
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