[RFC] New category proposal, i18n
Alexey Shuvaev
shuvaev at physik.uni-wuerzburg.de
Tue Jun 23 17:52:50 UTC 2009
On Tue, Jun 23, 2009 at 10:13:48AM -0400, Thomas Abthorpe wrote:
> 2009/6/23 Chris Rees <utisoft at googlemail.com>:
> > 2009/6/23 Doug Barton <dougb at freebsd.org>:
> >> Thomas Abthorpe wrote:
> >>> To have localization, you need internationalization, so from this, I stand by
> >>> my original proposal of i18n.
> >>
> >> I have no objection to your reasoning, but continue to object to the
> >> specific string. If you're going to go down this road then
> >> "internationalization" would be the better choice.
> >>
> >> Doug
> >>
> >
> > I would agree with Doug. We're in the days of tab-completion, and
> > typing 'in<TAB>' will suffice to get there. I for one *hate* numbers
> > in paths; it takes one's hand off the letters. Also, I had to look up
> > i18n to find out what it was... Categories should be immediately
> > descriptive.
> >
Hard to achive... x11-wm, x11-fm, audio vs. multimedia, ...
> > Also, the French have to use Shift to type numbers; it's even more of
> > a pain for them!
> >
Unrelated problem.
head -50 test.c
kill -s KILL 46129
man 3 printf
mount /dev/da0a mnt/
I think you can't avoid using numbers in command-line.
BTW, numbers are much better than spaces or localized characters:
'Мои документы' ( == 'My Documents')
> > Chris
> >
> >
>
> You have struck a chord with numbers in the path, reminds me of the
> pre-Xorg days with /usr/X11R6, not sure what I disliked more, the
> capital letters or the numbers!
>
> I hereby relent, and yield to the logic of the arguments placed before
> me, I now agree that using internationalization for the category name
> is a better idea.
>
Well, if the new category supposed to be real,
I don't like 'internationalization' name.
The reason? Very simple.
For now I get:
~> ls /usr/ports/
CHANGES archivers finance misc shells
COPYRIGHT astro french multimedia sysutils
GIDs audio ftp net textproc
INDEX-8 benchmarks games net-im ukrainian
KNOBS biology german net-mgmt vietnamese
LEGAL cad graphics net-p2p www
MOVED chinese hebrew news x11
Makefile comms hungarian packages x11-clocks
Mk converters irc palm x11-drivers
README databases japanese polish x11-fm
Templates deskutils java ports-mgmt x11-fonts
Tools devel korean portuguese x11-servers
UIDs distfiles lang print x11-themes
UPDATING dns mail russian x11-toolkits
accessibility editors math science x11-wm
arabic emulators mbone security
which fits fine in one 80x25 terminal window.
With the new category:
~> ls /usr/ports/
CHANGES devel net-p2p
COPYRIGHT distfiles news
GIDs dns packages
INDEX-8 editors palm
KNOBS emulators polish
LEGAL finance ports-mgmt
MOVED french portuguese
Makefile ftp print
Mk games russian
README german science
Templates graphics security
Tools hebrew shells
UIDs hungarian sysutils
UPDATING internationalization textproc
accessibility irc ukrainian
arabic japanese vietnamese
archivers java www
astro korean x11
audio lang x11-clocks
benchmarks mail x11-drivers
biology math x11-fm
cad mbone x11-fonts
chinese misc x11-servers
comms multimedia x11-themes
converters net x11-toolkits
databases net-im x11-wm
deskutils net-mgmt
which is too long.
You need to scroll to see the whole content of the folder.
About the topic: from
http://lists.freebsd.org/pipermail/freebsd-ports/2009-June/055424.html
> It is my intention for ports that do localization related work
> would remain in their existing category, and if appropriate
> we could add the new name to CATEGORIES.
from:
http://lists.freebsd.org/pipermail/freebsd-ports/2009-June/055463.html
> To paraphrase a couple of key points
>
> "Localization refers to the adaptation of a product, application
> or document content to meet the language, cultural and other requirements
> of a specific target market (a "locale")."
>
> ...
>
> "Internationalization is the design and development of a product,
> application or document content that enables easy localization
> for target audiences that vary in culture, region, or language."
>
> To have localization, you need internationalization, so from this,
> I stand by my original proposal of i18n.
>From the above my conclusion is, if gettext stays in devel
and kde3-i18n-ca goes to new category, this new category is
for *localized* versions of different applications but not for tools
that help doing *internationalization*.
In any case (I mean the name of the new category), given that some
ports will go into it and some will stay in their current categories
I think the new category should be virtual, not real.
0.02$,
Alexey.
More information about the freebsd-ports
mailing list