Localizable location? #1390
Comments
|
I would support this - I always wondered about the |
|
If you consider to provide a selected list of some common locations, from the top of my head with a brief glance at this Wikipedia list
Maybe also:
|
|
Hmmm. Thing is, this will probably be a huge burden to maintain and we probably have to add all sorts of cities once people start asking for it. (At some point we might even run into performance issues if we take it too far.) Do we really want this? |
moewew
added
enhancement
localisation
|
We could do a short list - any others need to be added by users - the above list isn't too long and I doubt there would be performance issues with that. |
|
My understanding of the objective might not be complete, but I imagine --
at a minimum -- that this rather incomplete list of 35 cities need to be
translated in the more than 40 supported languages in BibLaTeX. In itself
that does not seem like an easy task
Paulo Ney
…On Tue, Oct 29, 2024, 5:33 PM plk ***@***.***> wrote:
We could do a short list - any others need to be added by users - the
above list isn't too long and I doubt there would be performance issues
with that.
—
Reply to this email directly, view it on GitHub
<#1390 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAR7WYR2DXVTWAT5ES7TBMTZ57WI7AVCNFSM6AAAAABQWXIYF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBVGI3TINZQGU>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
I think the idea is more that we put in the code and commented placeholders to allow this to work and then people can send pull requests etc. to update the various language files over time. |
That's what I was meaning to suggest. |
|
To expand a bit, one possibility would be to use just the English city names as bibstrings. This way, people will just get the English name if no localization exists in their language. A drawback of this is that there might be cases where the name is localized without people being aware of it (say, they have "Vienna and London" in their entry and suddenly get "Vienne/Londres" or even "Vienne/London". This would not happen with lowercased keys, but then, the would just get the key ("vienna/London"). On the other hand, they only get this if they explicitly entered it. |
|
Would the list be part of the LBX files?
…On Wed, Oct 30, 2024, 6:05 AM Jürgen Spitzmüller ***@***.***> wrote:
To expand a bit, one possibility would be to use just the English city
names as bibstrings. This way, people will just get the English name if no
localization exists in their language.
A drawback of this is that there might be cases where the name is
localized without people being aware of it (say, they have "Vienna and
London" in their entry and suddenly get "Vienne/Londres" or even
"Vienne/London". This would not happen with lowercased keys, but then, the
would just get the key ("vienna/London"). On the other hand, they only get
this if they explicitly entered it.
—
Reply to this email directly, view it on GitHub
<#1390 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAR7WYW6C7QACUEG24JR6ATZ6CONFAVCNFSM6AAAAABQWXIYF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBWGI2TGNRTGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
If it is decided that biblatex provides a selection of common locations, then this goes to the Let me rephrase that I think the feature would be very useful even if biblatex itself does not provide any of these strings out of the box (although I think that the list of locations with very common publishers is finite) |
|
The list itself does need some work. "Leuven" writes with a "v" in English;
it is way too Nordic, with only one city in the Southern hemisphere...
I am in a camp that believes the language on a biblio entry should be
unique and (in most cases) the language of the bibliography entry source
and NOT the main language of the document -- because one needs to be able
to locate it and that will give you the best chances.
I really like the standardization and verification of correctness, not only
on this field, but also in several other ones, but a minimal translation
would be really necessary to make it useful.
PN
…On Wed, Oct 30, 2024, 8:04 AM Jürgen Spitzmüller ***@***.***> wrote:
Would the list be part of the LBX files?
If it is decided that biblatex provides a selection of common locations,
then this goes to the *.lbx files, as any other bibstrings. As with other
bibstrings as well, any individual additions go elsewhere (for instance, a
personal style or the preamble).
Let me rephrase that I think the feature would be very useful even if
biblatex itself does not provide any of these strings out of the box
(although I think that the list of locations with very common publishers is
finite)
—
Reply to this email directly, view it on GitHub
<#1390 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAR7WYRM7MZKO2V3JWCVJETZ6C4M3AVCNFSM6AAAAABQWXIYF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBWGYYTMNRSGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
We have |
Thanks, corrected that one. But the list was meant as a first approximation only, anyway (and it's also arguable collected very much from my germanocentric perspective) |
|
Yes, but in the whole there are a few pieces missing -- coverage in LBX
being one of them. It is easy for a single document in English to demand
several LBX files. We are missing several important ones in the world of
publishing like Latin, Chinese and Japanese. The feature is nice but it
will be as useful as the translation coverage.
PN
…On Wed, Oct 30, 2024, 8:35 AM Jürgen Spitzmüller ***@***.***> wrote:
I am in a camp that believes the language on a biblio entry should be
unique and (in most cases) the language of the bibliography entry source
and NOT the main language of the document -- because one needs to be able
to locate it and that will give you the best chances.
We have autolang to control for that, no?
—
Reply to this email directly, view it on GitHub
<#1390 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAR7WYTD46WJI4JZQCVIOKLZ6C77NAVCNFSM6AAAAABQWXIYF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBWG42DQNZRGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I understand the concern, but I don't see how this is related to this requested feature particularly. This is a general issue that concerns all bibstrings. In any case, having the possibility to localize location at all will make a crucial difference to people who need it -- also if they have to come up with their own bibstring translations. |
|
It is related because -- it is an effort towards standardization and
verification -- and other requests in the same direction have not been as
well received.
PN
…On Wed, Oct 30, 2024, 11:12 AM Jürgen Spitzmüller ***@***.***> wrote:
I understand the concern, but I don't see how this is related to this
requested feature particularly. This is a general issue that concerns all
bibstrings. In any case, *having* the possibility to localize location at
all will make a crucial difference to people who need it -- also if they
have to come up with their own bibstring translations.
—
Reply to this email directly, view it on GitHub
<#1390 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAR7WYVJZ52GHGEZ4JEKWJ3Z6DSLLAVCNFSM6AAAAABQWXIYF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBXGI4TSNZQGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Maybe useful for matching: https://www.publishersglobal.com/directory/list-cities/sort/popular |
|
Uau! Much better list and it is linked to the publishers located there,
which in trade the usefulness of the feature a huge lot!
We would have to write a crawler to get all this info out.
…On Sun, Nov 3, 2024, 1:35 AM Jürgen Spitzmüller ***@***.***> wrote:
Maybe useful for matching:
https://www.publishersglobal.com/directory/list-cities/sort/popular
—
Reply to this email directly, view it on GitHub
<#1390 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAR7WYSKATA6OCMD7JX6GDLZ6WRXNAVCNFSM6AAAAABQWXIYF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTGI4TEOBXGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
The data is straight from the ISBN database, and a bit on the "old" side,
my guess is about 20 years old...but it has been slightly curated -- it
corrects some typos in the ISBN list.
If anyone knows how to obtain the list from the original source (and
up-to-date) that would be a real plus. We do get ISBN ranges from them in a
regular way - for the ISBN checker - so maybe we can get this too.
…On Sun, Nov 3, 2024, 5:39 AM Paulo Ney de Souza ***@***.***> wrote:
Uau! Much better list and it is linked to the publishers located there,
which in trade the usefulness of the feature a huge lot!
We would have to write a crawler to get all this info out.
On Sun, Nov 3, 2024, 1:35 AM Jürgen Spitzmüller ***@***.***>
wrote:
> Maybe useful for matching:
> https://www.publishersglobal.com/directory/list-cities/sort/popular
>
> —
> Reply to this email directly, view it on GitHub
> <#1390 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAR7WYSKATA6OCMD7JX6GDLZ6WRXNAVCNFSM6AAAAABQWXIYF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTGI4TEOBXGE>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
|
Sorry for the mangled text, I was on the phone and auto-correct tripped it
... should have been:
Uau! Much better list and it is linked to the publishers located there,
which will increase the usefulness of the feature a huge lot! We can add
the publishers to the localization.
On Sun, Nov 3, 2024 at 1:39 AM Paulo Ney de Souza ***@***.***>
wrote:
… Uau! Much better list and it is linked to the publishers located there,
which in trade the usefulness of the feature a huge lot!
We would have to write a crawler to get all this info out.
On Sun, Nov 3, 2024, 1:35 AM Jürgen Spitzmüller ***@***.***>
wrote:
> Maybe useful for matching:
> https://www.publishersglobal.com/directory/list-cities/sort/popular
>
> —
> Reply to this email directly, view it on GitHub
> <#1390 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAR7WYSKATA6OCMD7JX6GDLZ6WRXNAVCNFSM6AAAAABQWXIYF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTGI4TEOBXGE>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
Many of the (larger) cities where publishers locate have different or differently spelled names in different languages (e.g., Wien -- Vienna -- Vienne -- Beć, ...; Brüssel -- Brussels -- Bruxelles, ...). In bibliographic entries, the publisher location normally should be given in the main language of the document.
So I wonder whether
\DeclareListFormat{location}should not use(actually just like patent location). Biblatex could include bibkeys for the most common publisher locations, but even if it didn't, it would help to maintain an own list. Currently I am working around this with
@strings which change depending on the document language.Another related issue which I am not sure how to deal with concerns the (mainly US?) convention to give state names (Cambridge, MA), the use and form (cf. Cambridge, Mass.) of which seems to depend on style. Maybe this could be approached via data annotation, or
\locstate{<bibkey>}macros. Anyways, this seems less central than the issue above.The text was updated successfully, but these errors were encountered: