previous page | next page
|
|
previous page | next page |
|
|
Main How to index Beginners More detail Programmers Internal files DIZNI How to use DIZNI How it works Bugs Scanners File formats ISV files Field reference guide Credits/links Producktion Index of indexes Various |
Known bugs, wishes, other issues
TO-DO list Dizni
This file contains an action list for the program Dizni.
Most action points are stored here in the form of ddb mails.
This file should only be edited by Harry Fluks.
Minor action points are marked with (at least) two @s in the source code of Dizni.
==================================================================
> From: Fluks, H.W.
> Sent: woensdag 9 maart 2005 10:17
> Subject: @@ abbrev-replacement in desc RE: Harry: Francois
> or/and(?) Ari: remarks on COA
>
> Johannes wrote:
>
> > Or is it too complicate[d] to replace a part of a string?
>
> Thomas wrote:
>
> > I assume it's not too complicated, but it might introduce problems.
> > Since DIZNI does not know which part of the string it
> should translate
> > into a full character name, it would just have to translate
> > every "DD",
> > "US", ... substring it finds, so we might have faulty
> > translations.
>
> This has been on my dizni-to-do-list for quite some time now.
> I plan to replace any abbreviations in an English desc
> automatically, under conditions:
> - the abbreviation is no longer than 3 characters;
> - at least 2 characters are upper case;
> - the abbreviation also occurs in the xapp.
>
> The combination of the three should minimise the number of
> errors (how many stories do we have where someone has a cd
> *and* the cd is spelled "CD" in the desc *and* Chip 'n' Dale appear?)
>
> There may be still some problems with unnatural looking
> sentences, for instance the fact that we use the full name
> "Donald Duck" where in a normal sentence we would just say "Donald".
> This can be solved, by giving a character a "nickname" (e.g.
> HDL = "the nephews"). In that case, also initial capitals
> should be taken into account.
>
> In the above I only talk about the English desc. If we want
> to do the same for other languages, there may be a problem
> where a character has different names in different stories
> (unless we define a generic nickname for every language).
>
> This all seems a lot of work anyway, and that's why it's
> still on my to-do-list.
> But it also sounds like a lot of fun, and that's why I didn't
> remove it from my to-do-list yet! 8-)
>
> --Harry.
==================================================================
@@ [version:country/entrycode] FIELD
> Stefan Persson
> Sent: dinsdag 27 september 2005 12:33
> Subject: Re: Relational model: version 2 (Paolo? Francois? Anyone?)
>
> On 2005? 9 27 () 11:43 am, Kjell_Cron said:
> > IMO, we should go in that direction, some time in the future.
> > It's not *such* a lot of work. It's much easier than identifying an
> > unidentified story.
> > We could create a d.dbv (versions) for all Egmont modifications.
>
> I fully agree with KCr, although I don't see any need for a
> d.dbv file.
> The original titles will still be the same as in the story
> files, and the
> rest of the data can be collected from the issue files (and DIZNI can
> complain about differing data). This way we could also list the DR
> multi-part stories in a (IMHO) way that's better than the
> current way: by
> using different STORYVERSIONs for each version. All we would
> need is one
> field for the issue input files that specifies the version,
> possibly by
> entering the entry code for any other copy of the same
> version. In the
> event of collecting, this could be generated automatically.
>
> Stefan
> Stefan Persson
> Sent: donderdag 6 oktober 2005 15:57
> Subject: Some thoughts on STORYVERSIONs
>
> A suggestion regarding STORYVERSIONs and the usage and syntax of the [re] field:
(IK DENK DAT HET BETER EEN ANDER VELD KAN WORDEN)
>
> An issue file may contain a [re] field using the syntax
> [re:country/entrycode] like this:
>
> xx/X 1a ... [re:yy/Y 2b]
> yy/Y 2b
>
> Used where:
> Issue files where [idc] and/or [changes] are filled in, and/or the story is unidentified.
>
> Result:
> - - DIZNI assigns the same STORYVERSION ID to both ENTRY IDs (instead of
> two different IDs for [changes] and [internal:@])
> - - We are certain that the items are identical
> - - No need for fake story codes
>
> Output:
> The [re] field is not carried over to the CSV file because the
> information already is given by the STORYVERSION ID being the same.
>
> STORYVERSION data:
> - - The concatenated credits, xapp and desc information from the various issue files.
> - - Any storycode used (usually an incomplete code).
> - - NO original title (in the case of unidentified stories), or the same
> title as that for the STORY that the same storycode refers to (in the case of changed stories).
>
> DIZNI warnings:
> - - The usual warnings about differing field data.
> - - New warning: [re] is filled in, but the storycode is identified without [changes] or [idc].
> - - New warning: [re] is filled in, but the field refers to an ENTRY which
> is identified without [changes] or [idc].
> - - New warning: [re] is filled in, but DIZNI can't find the ENTRY it refers to.
> - - New warning: Different ENTRY have different storycodes (usually incomplete codes).
> - - New warning: Different text in the [changes] field for different ENTRY.
>
> Since [idc] items *are* linked to a STORY, some of the above things need
> to be handled differently for [idc] items, so maybe a different field
> needs to be used for the [idc] case?
>
> Stefan
==================================================================
> From: Francois Willot
> Sent: woensdag 27 juni 2001 14:30
> Subject: RE Harry, Francois: Newspaper strips
>
> >From: Fluks, H.W.
>
> >2. For a reprint of a sequence of strips, we use the comment field to
> >indicate the exact start and ending dates, if different from
> the dates
> >in the story file. It's up to the indexer to decide if the dates
> >are different enough to have a [changes:] field. For instance, some
> >Dutch YM stories have a slightly different start date. But since the
> >start of the story is a bunch of loose gags, I don't think it's worth
> >a [changes:].
>
> I think that it's preferable to specify the start and end
> dates used in the
> reprint in the [changes:] field in such cases. If strips are
> missing, it's
> also nice to add a note about that.
>
> But what about start dates that are older than the start
> dates given in the
> story file? That is, a few strips are reprinted, which are in
> fact the end
> of the previous continued story.
> In the "Mighty Whale Hunter" Mickey story, there are two
> common start dates,
> one of them being 4 or 5 strips before the other.
> Can we just index the individual strips with their dates ("YM
> 38-07-06"
> etc.) before YM 036, with a note?
>
> I don't know how much work it is, but it could be interesting
> to make Dizni
> recognizes that "YM 38-07-06" is a part of "YM 034".
@@@@ GOEIE REDEN OM STRIPS APART TE MELDEN!
>
> That may be useful for the mini-stories from the Mickey Sunday Pages.
> E.g. "Mickey's nephews" is sometimes reprinted as one whole
> story, or as
> several gags.
>
> Francois
==================================================================
@@ genereren van scan-namen e.d. is wat onduidelijk. Werkt het goed en kan het beter ge-integreerd worden?
==================================================================
I now see an old (March 16) mail from François in my to-do mailbox:
> I can think of the following: we make up separate issue
> scans, that should
> be present only when the cover of an issue is made up of
> several items.
@@@ SCANS VAN COVERS WAAR MEER DAN 1 ITEM OP STAAN
> These scan s have file names like: us_wdc_001.jpg. Dizni
> produces a file
> relating scans and issues and when such a scan is found, it
> is prefered to
> any other image for the cover of that issue on COA.
That might be a good idea.
--Harry.
==================================================================
> Sent: vrijdag 10 november 2006 18:22
> Subject: Titles on h2 lines
>
> Harry:
> >There have been some differences in handling titles on h2 lines.
> >There are 2 possibilities:
> >- h2 title overrules h1 title;
> >- h2 title should be concatenated after h1 title
> >
> >I see the overrule option in the Finnish file:
> >
> >Z h1 Sekalaiset fanzinet ja muut artikkeleja
> >ZAK h2 Ankkoja Kaapelissa
> >ZALPA h2 Ankkalinna palaa!!!
>
@@@> Yes, the h2 title overruling would be preferred in there.
>
> Or would it be easier if entries were changed and all the h2 series
> would be indexed separately? With the new [category:] fields they'd
> not be such a mess as earlier.
>
> But still, in some cases it'd be useful if COA user would see the
> whole serie (all the different h2 subtitled issues) in the same page:
>
> P h1 Aku-Palat, JatkoPalat, yms. muut -Palat
> P-AP h2 Aku-Palat
> P-JP h2 JatkoPalat
> P-KP h2 KesäPalat
> P-VP h3 VauhtiPalat
>
> So some h2-title overruling system would be really good. And in
> some cases if h3 titles would concatenate with h1 titles, or
> overrule h1 titles totally (when there's no h2-lines):
>
> M h1 Jättikirjat
> M 1972 h3 Minä Aku Ankka
> M 1973 h3 Minä Roope-setä
> M 1974 h3 Minä Mikki Hiiri
>
>
> Stefan:
> >>So I think we need a good and uniform way to handle h2 titles.
> >
> >Or we could use something similar to title prefixes to
> specify what kind of
> >title it is. Maybe also useful for h3 titles.
>
> Or develope a some kind of [title:] field system to be used in the
> needed h1 lines?:
>
> AAA h1 [title:h2] (- h2 titles overrule h1 title)
> BBB h1 [title:h3] (- h3 titles overrule h1 title)
> CCC h1 [title:h1,h2] (- h2 titles concatenatd after h1 title)
> DDD h1 [title:h1,h3] (- h3 titles conc. after h1 title)
> EEE h1 (- h1 title used only, the current method)
>
> The special effect would take place only where it is desired.
> Other titles would stay unmodified.
>
> - Simo
==================================================================
> Sent: woensdag 7 februari 2007 18:59
@@> Subject: Re: DIZNI log messages
>
> Maybe some warnings could be added:
> * Character
|
|
This page was generated on 2008-04-18 by DVEGEN 4.8d © Harry Fluks 2003.
For more information contact Harry Fluks (hfl at inducks.org - replace the at) |