Is het criterium dat de oorspronkelijke titel niet wordt genoemd als we te maken hebben met Arabische , Griekse , Chinese letters enzovoorts ?
Is the criterion that the original title is not mentioned when we are dealing with Arabic, Greek, Chinese letters and so on?
Nooit van gehoord. Deze titels worden doorgaans door middel van transcriptie weergegeven in onze lettertekens.
Never heard of it. These titles are usually transcribed in our characters.
Bijvoorbeeld :
Zie
https://en.wikipedia.org/wiki/Arabesques_(short_story_collection)
Dan zie je de oorspronkelijke titel in het Russisch , dat pakt LD niet. Nu is bij gebrek aan beter als oorspronkelijke titel de Nederlandse titel overgenomen. Niet zo boeiend wellicht.
https://www.lastdodo.nl/nl/areas/4352457-petersburgse-vertellingen
Arabesken of Petersburgse vertellingen (1835-'42)
- Nevski Prospekt
- Dagboek van een gek
- De neus
- Het portret
- De mantel
- De kales
For example:
See
https://en.wikipedia.org/wiki/Arabesques_(short_story_collection)
Then you see the original title in Russian, LD doesn't take that. Now the Dutch title has been taken over as the original title for lack of anything better. Perhaps not so exciting.
https://www.lastdodo.nl/nl/areas/4352457-petersburgse-vertellingen
Arabesques or Petersburg tales (1835-'42)
- Nevsky Prospekt
- Diary of a madman
- The nose
- The portrait
- The Robe
- The kales
De Nederlandse titel is niet juist. Zoals ik al zei: een transcriptie (= fonetische omzetting) is wel juist. Die kun je vaak vinden in de catalogus van de KB.
The Dutch title is incorrect. As I said: a transcription (= phonetic conversion) is correct. You can often find this in the KB catalog.
Enigma was me weer voor .... Potjandokie
Enigma beat me again .... Potjandokie
Minder gebruikelijke diakritische tekens worden in de catalogus niet ondersteund, maar sommige niet-westerse alfabetten soms wel, in sommige rubrieken.
Ik weet dat het in de speldjesrubriek wel lukt (zie bv. 3219955) in de velden Titel en Bijzonderheden, maar niet in de overige velden (en niet in de Historie).
Omdat het dus blijkbaar niet per definitie onmogelijk is, vraag ik me af of er bij het ontwerp van de nieuwe pagina's niet naar dit probleem gekeken is.
Of is het een functie die in de onderliggende database van de catalogus aangepast moet worden?
Less common diacritics are not supported in the catalog, but some non-Western alphabets sometimes are, in some sections.
I know that it will work in the pins section (see e.g. 3219955 ) in the Title and Details fields, but not in the other fields (and not in the History).
Since it is apparently not by definition impossible, I wonder if this problem was not considered in the design of the new pages.
Or is it a function that needs to be adjusted in the underlying database of the catalog?
Of is het een functie die in de onderliggende database van de catalogus aangepast moet worden?
Gaan we uitzoeken.
Staat die tekst er al in vanaf de eerste invoer van het item? Want in de historie is dat dus niet goed te zien met die vraagtekens.
Or is it a function that needs to be adjusted in the underlying database of the catalog?
Let's find out.
Is that text already there from the first entry of the item? Because in history that is not clearly visible with those question marks.
Die Hebreeuwse tekens heb ik toegevoegd in Versie 2.
Het lukt ook met Cyrillische tekens, bv. 6239665.
(Het is trouwens wel telkens een krankzinnig karwei om met een online toetsenbord al die tekens te identificeren en correct te typen.)
Overigens, sommige velden geven een foutmelding als je het probeert in te vullen, terwijl andere de invoer wel accepteren maar vraagtekens weergeven op de pagina. In dat laatste geval heeft de database de wijziging vermoedelijk wel correct opgeslagen.
I added those Hebrew characters in Version 2.
It also works with Cyrillic characters, eg 6239665 .
(By the way, it is always an insane job to identify all those characters with an online keyboard and type them correctly.)
By the way, some fields give an error when you try to fill it in, while others accept the input but display question marks on the page. In the latter case, the database will probably have saved the change correctly.
Of is het een functie die in de onderliggende database van de catalogus aangepast moet worden? @Stripspeldjes @Collectioneur
Waarschijnlijk wel, dat kunnen alleen de database beheerders : UTF8..maar in welke vorm generic of unicode en dan de collatie utf8mb4 etc.. (ja utf8 wordt hier gebruikt, welke ?)
Te technisch om even verschillen uit te leggen.
Belangrijkste in deze (dat weten of is afgesproken? de dbase beheerders ) dat de juiste vorm (in gebruik) alle tekens kan laten zien, maar heeft ook weer gevolgen voor de snelheid van de queries die opgeroepen worden.
Aannemend dat die dbase groot is, is dat een belangrijk item...
Terzijde: een en ander is mogelijk ook oorzaak vindend of er gebuik wordt gemaakt van een 'vorm' die nog deels gebruikt maakt op oude pre utf 8 regels zoals latin.
@Collectioneur meldt : Gaan we uitzoeken..
Mogelijk ligt hier in dit gebeuren de oorzaak.
Or is it a function that needs to be adjusted in the underlying database of the catalog? @Stripspeldjes @Collectioneur
Probably so, only the database administrators can: UTF8 ... but in any form generic or unicode and then the collation utf8mb4 etc .. (yes utf8 is used here, which one?)
Too technical to explain differences.
Most important in this (that know or has been agreed? The dbase administrators) that the correct form (in use) can show all characters, but also has consequences for the speed of the queries that are called.
Assuming that dbase is large, that's an important item ...
As an aside: this may also be the cause of whether a 'form' is used that is still partly used on old pre utf 8 rules such as latin.
@Collectioneur reports: Let's find out ..
This may be the cause of this.