Re: [RFR] templates://openoffice.org/{templates}
Rene Engelhard wrote:
>> Tamil and Telugu aren't "Indic languages", they're Dravidian
>> languages. Unfortunately we can't just substitute "Indian" either -
>> Bangla is Indic but not Indian.
>>
>> Of course this is really just another case of confusion between
>> writing systems and languages. This is a metapackage for
>> localisation in Indic *scripts*. [...]
>
> That was not the intention. It a metapackage for "languages spoken
> in India". I don't care about what their script is or whether it's
> actually a "Indic language" from language definition.
Oh, and openoffice.org-l10n-bn is included for the benefit of Bangla
speakers in West Bengal? Well, that simplifies things; if you just
mean "Indian", there's no reason to say anything but "Indian".
>>> + This package contains the GTK plug-in for drawing OOo's widgets with
>>> + GTK+ and a GTK/GNOMEish File Picker when running under GNOME. It also
>>> + contains a Quickstarter for the "notification area".
>>
>> Fixing some capitalisation and hyphenating "plug-in".
>>
>> [...]
>>> - This package contains the GNOME VFS support and a GConf backend.
>>> + This package contains the GNOME VFS support and a GConf back-end.
>>
>> Likewise standardising on hyphenated "back-end".
>
> Where is that standardized please? back-end looks awful. I can't barely
> live with plug-in...
In dictionaries; in fact paper dictionaries still tend to lag
behind current usage by recommending "back end", only grudgingly
accepting the hyphenated version. Online dictionaries such as
dictionary.reference.com accept "back-end", and that does seem to
be what most ordinary people write - if you ask Google for
"backend", the top hits are all for "back-end".
This is another example of the common situation where the
technical specialist minority (the people who have to use the word
most) are accustomed to treating it as a basic vocabulary item; but
for outsiders (the end-users this text is written for) it's always
the unfamiliar jargon version that "looks awful".
>>> - You can extend the functionality of this by installing these packages:
>>> - .
>>> - * openoffice.org-evolution: Evolution addressbook support
>>> - * evolution
>>> + You can extend its functionality by installing these packages:
>>> + * evolution: groupware suite;
>>> + * openoffice.org-evolution: Evolution addressbook support.
>>
>> Alphabetical order, and including an explanation of what Evolution
>> actually is (since the name conveys nothing).
>
> People who use Evolution know.
People who are already using Evolution hardly need to be reminded to
install it by an OOo package description. This text serves as a
pointer for newcomers who might want a groupware suite to go with
their office suite.
>> Never use "thesauri" unless you specifically intend to start an
>> argument about plural morphology.
>
> Thesauri is the correct plural.
It's certainly _a_ correct plural, listed in dictionaries as an
alternative to the equally correct regular English plural
"thesauruses". Unfortunately it's like "octopi" - it's impossible
to use any plural form in public without starting an argument, so I
advise avoiding the distraction. You don't have to take my advice
if you enjoy using the Latinate version, though.
>>> Suggests: hunspell-dictionary-en-gb | myspell-dictionary-en-gb, openoffice.org-hyphenation-en-gb, openoffice.org2-thesaurus-en-gb, openoffice.org-help-en-gb
>>> Conflicts: openoffice.org-core (<< ${base-version}), openoffice.org-core (>= ${base-version}.1), openoffice.org2-l10n-en-gb
>>> Replaces: openoffice.org2-l10n-en-gb
>>> -Description: full-featured office productivity suite -- English_british language package
>>> +Description: OOo suite - British English language pack
>>
>> There's no such language as English_british. I would suggest
>
> All of them are autogenerated and can handle only stuff without spaces.
So instead it generates non-words; couldn't it at least be
persuaded to generate strings like "British-English"?
>>> -Description: full-featured office productivity suite -- Norwegian language package
>>> +Description: OOo suite - Norwegian Bokmal language pack
>>
>> The English name of the dominant written standard in Norway is
>> "Norwegian Bokmal" (or "Bokmål", but we'll get away with ASCII).
>> See following.
>
>> [...]
>>> -Description: full-featured office productivity suite -- Norwegian_nynorsk language package
>>> +Description: OOo suite - Norwegian Nynorsk language pack
>>
>> The minority written standard for Norwegian.
>
> So what is wrong here? Nowergian is the dominiant one (Bokmal) and
> _nynorsk is the extra one. What are you complaining about?
Nynorsk is a "Norwegian language pack" too, but Bokmål is hogging
that title. On the other hand not mentioning Bokmål does have the
advantage that you don't have to decide whether you're writing it
with a-ring.
>>> -Description: full-featured office productivity suite -- Chinese_traditional language package
>>> +Description: OOo suite - Traditional Chinese language pack
>>
>> Another one that's just a difference of standard writing systems,
>> not languages.
>
> They're two different locales everywhere.
I don't follow; are you disagreeing? Don't worry, I'm not asking
for language packs to be renamed "standard writing system packs"!
>>> -Description: full-featured office productivity suite -- English_american help
>>> +Description: OOo suite - American English help
>>
>> If there was a separate openoffice.org-l10n-en-ca then I suppose
>> Canadians would be entitled to quibble about whether "American" was
>> specific enough, but never mind.
>
> Would you like English_usamerican better? I don't.
If I thought it mattered I'd be asking for "US-English", but this
is like the GB-versus-UK issue: not worth worrying about.
>> [...]
>>> -Description: OpenOffice.org UNO runtime environment -- public shared libraries
>>> +Description: OpenOffice.org UNO runtime environment - shared libraries
>>
>> Just shortening it; would you get packages of private shared
>> libraries?
>
> Why not? OOo is full of private libraries? What you do think e.g
> -evolution actually is?
A shared library that lets OpenOffice.org binaries access the
Evolution addressbook routines? Does that really count as private?
Still, never mind that example, obviously you do get clearly
non-public ones too; I wasn't thinking. I just saw "runtime" plus
"public shared libraries" and had a rush of optimism that I could
squeeze out some redundancy...
Oh, and if you're wondering why I don't suggest "run-time", it's
because non-technical users are unlikely to need to decide whether
they want this installed...
>>> -Description: OpenOffice.org UNO runtime environment -- public shared library debug symbols
>>> +Description: OpenOffice.org UNO runtime environment - debug symbols
>>
>> Shrtn!
>
> Buggy. This is not ure-dbg. This is uno-libs3-dbg. Just for the libs.
> What you describe here'd be ure-dbg.
Which is listed just below, so I should have noticed it. Okay. if
there's no slack in the package-specific part, the alternatives are
leaving it super-long or trimming the boilerplate part. Really
squeezing the boilerplate could get it down to:
Description: OOo suite URE - public shared library debug symbols
and so on; that's overdoing it, but surely there must be some
sensible middle ground...
>>> - You can extend the functionality of this by installing these packages:
>>> - .
>>> - * konqueror / kmail
>>> - * openoffice.org-kab: KDE Addressbook support
>>> + You can extend its functionality by installing these packages:
>>> + * konqueror/kmail;
>>> + * openoffice.org-kab: KDE Addressbook support.
>>
>> Adjusting the punctuation. Why do konqueror/kmail share a bullet?
>
> Because they're what OOo opens for mailto: and other URLS when it is under
> KDE. That's different from -kab where you need to select kab as data source.
So maybe it could add a hint like
* konqueror/kmail: support for common URI schemes;
(though I'd be happier if there was a way of reducing the jargon.)
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: