Would you please merge from papyri.info to dev.papyri.info to include this text (Arabic only), which I have just added to papyri.info

http://papyri.info/ddbdp/p.worp;;65

could you please display the line numbers as in the edition, which you will find in .doc form here:

http://147.142.225.252/Xcoded/PWorp/Text%2065def.doc

i.e. Arabic numbers without a dot (neither before nor after the numeral)

and running RTL

and as in the rest of papyri.info in fives (5, 10, 15, 20 etc)

This seems to be relatively standard practice in modern Arabic editions. I have spoken to Lajos and Usama who were alright with this. (Not to say that others will be. There will almost certainly be others who do not like it, but it would be something to show)

Simply to make an issue for this, even if we have to step back from it.

It would be great to get rid of the "na" in DCLP files. Here is an example:

https://github.com/papyri/idp.data/blob/master/DCLP/69/68357.xml#L15

<idno type="dclp-hybrid">na;;68357</idno>

This should (in a better world) be

<idno type="dclp-hybrid">tm;;68357</idno>

After all it is a tm number and should be called such (a litpap.info aberration, sorry!). Users would be able to understand it etc. etc.

Obviously editor knock on effects will have to be considered.

The following new series were added (relatively) recently to collection.rdf
https://github.com/papyri/idp.data/blob/master/RDF/collection.rdf#L1281-L1314

On http://papyri.info/browse/hgv/
P.Ryl.Copt. is displayed
O.Frange is displayed
P.Monts.Roca is displayed
P.Turku is displayed
P.Aktenbuch is displayed

P.Cair.Preis.2 is NOT displayed
on analogy with P.Gen. possibly does not have to show separately as all texts are reedited
P.Stras.Copt. is NOT displayed
Short Texts is NOT displayed
T.BM Arlt is NOT displayed
P.KRU is NOT displayed
ZPE is NOT displayed

On http://papyri.info/browse/ddbdp/

http://papyri.info/ddbdp/p.ryl.copt is displayed
http://papyri.info/ddbdp/o.frange is displayed

http://papyri.info/ddbdp/p.cair.preis.2 is NOT displayed is not on tree (https://github.com/papyri/idp.data/tree/master/DDB_EpiDoc_XML)
needs to be treated analogously to
https://github.com/papyri/idp.data/tree/master/DDB_EpiDoc_XML/p.gen.2/p.gen.2.1
https://github.com/papyri/idp.data/tree/master/DDB_EpiDoc_XML/p.cair.preis.2/p.cair.preis.2.1
http://papyri.info/ddbdp/p.monts.roca is NOT displayed is on tree
https://github.com/papyri/idp.data/tree/master/DDB_EpiDoc_XML/p.monts.roca/p.monts.roca.4
http://papyri.info/ddbdp/p.turku is NOT displayed is not on tree
http://papyri.info/ddbdp/p.aktenbuch is NOT displayed is on tree
https://github.com/papyri/idp.data/tree/master/DDB_EpiDoc_XML/p.aktenbuch
http://papyri.info/ddbdp/p.stras.copt is NOT displayed is not on tree
http://papyri.info/ddbdp/short.texts is NOT displayed is not on tree
http://papyri.info/ddbdp/t.bm.arlt is NOT displayed is not on tree
http://papyri.info/ddbdp/p.kru is NOT displayed is on tree
https://github.com/papyri/idp.data/tree/master/DDB_EpiDoc_XML/p.kru
http://papyri.info/ddbdp/zpe is NOT displayed is not on tree

Would you, please, do a reindex and make sure that all the files that are not at present displayed are all visible in the relevant places. Many thanks.

Hello, Hugh, may I please ask you to do a re-index of all ddb and hgv files this weekend.

As of today (15 May 2019) the Biblio search does not function, as far as I can see.

http://papyri.info/bibliosearch

I entered the name Hagedorn

Is the return.
The TM# with a box at the top left seems strange to me.

On: http://papyri.info/docs/about

"About: DDbDP" in the footer points to http://idp.atlantides.org/trac/idp/wiki/DDBDP instead of http://papyri.info/docs/ddbdp (as it does on most other pages)

Spotted by @gabrielbodard.

An attempt to explain these problems was also made at:
papyri/sosol#134.

Temporarily the editor is down. When it is up again I shall complete the issue. With instructions of where I would like to see the information displayed.

This issue concerns http://papyri.info/ddbdp/o.berenike;3;333 . I voted on and finalized the translation of the Duke text, but the syncing mechanism doesn't seem to have pushed the translation through to the HTML.

Hugh, would it be possible for you to fix the following quickly (or does it need a full re-index)?
This weekend I created a new series: p.heid.arab
papyri/idp.data@25caeb1
With this i renamed two files
https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/p.heid.arab/p.heid.arab.1/p.heid.arab.1.1.xml
and
https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/p.heid.arab/p.heid.arab.1/p.heid.arab.1.3.xml
with there respective metadata files
https://github.com/papyri/idp.data/blob/master/HGV_meta_EpiDoc/HGV46/45353.xml
and
https://github.com/papyri/idp.data/blob/master/HGV_meta_EpiDoc/HGV107/106482.xml

Now
http://papyri.info/hgv/45353
and
http://papyri.info/hgv/106482
display nicely, but without relevant Arabic text.
http://papyri.info/ddbdp/p.heid.arab;1;1
and
http://papyri.info/ddbdp/p.heid.arab;1;3
return

HTTP Status 404 -
type Status report
message
description The requested resource () is not available.
Apache Tomcat/7.0.16

It would be really great to have this showing today if possible. Would facilitate working with Andreas Kaplony towards getting Arabic into papyri.info.

Something strange going on, which I do not understand.

https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/stud.pal/stud.pal.5/stud.pal.5.119.xml
exists.
http://papyri.info/ddbdp/stud.pal;5;119/source
makes clear that the XML source is part of papyri.info

http://papyri.info/ddbdp/stud.pal;5;119/rdf
has lots of relationships

http://papyri.info/search?STRING=(%23%CE%B1%CF%83%CF%84%CE%B9%CE%BA%CE%BF%CF%85)&no_caps=on&no_marks=on&target=text&DATE_MODE=LOOSE&DOCS_PER_PAGE=15&STRING1=%23%CE%BB%CE%BF%CE%B3%CE%BF%CF%85&target1=TEXT&no_caps1=on&no_marks1=on&STRING2=%CE%94%CE%B9%CE%BF%CF%83%CE%BA%CE%BF%CF%81%CE%BF%CF%85&target2=TEXT&no_caps2=on&no_marks2=on

leads one to

clicking on this

http://papyri.info/ddbdp/stud.pal;5;119
returns:
HTTP Status 404 -

I cannot work out what is wrong here. Would you please look and then find a way to make

http://papyri.info/ddbdp/stud.pal;5;119

appear so that it can be viewed and opened in the editor.

Many thanks!

When the Navigator displays the aggregated Metadata and Text files, there is a link to the source of the Metadata (i.e. Link back to HGV). E.g. go to
http://papyri.info/ddbdp/bgu;6;1215
one sees
BGU 6 1215 [source] [xml]
when one clicks [source] it goes to
http://aquila.papy.uni-heidelberg.de/Hauptregister/FMPro?-db=hauptregister_&TM_Nr.=7306&-format=DTableVw.htm&-lay=Liste&-find
where TM_Nr.=7306, was how this was built
It should now go to
http://aquila.zaw.uni-heidelberg.de/hgv/7306
This is built analogously to when on clicks on [xml]
http://papyri.info/hgv/7306/source

When you are working on getting sync to work in the new environment with ddb, hgv and the new dclp stuff, please check that biblio is also being updated.
So far biblio is only fully up-to-date after a complete re-index.

If you call up
http://dev.papyri.info/search?&COLLECTION=dclp&SERIES=p.heid&VOLUME=1
then go to the first record
http://dev.papyri.info/dclp/59735?rows=2&start=0&fl=id,title&fq=collection:dclp&fq=(ddbdp_series:p.heid+OR+hgv_series:p.heid+OR+dclp_series:p.heid)&fq=(ddbdp_volume:1+OR+hgv_volume:1+OR+dclp_volume:1)&p=0&t=25

one sees

and it works

Since Monday of this week sync has choked

{
  "success": true,
  "status": "Syncing files."
  "started": "Mon Oct 17 11:23:05 EDT 2016"
  "last": "Mon Oct 17 11:23:05 EDT 2016"
}

Would you please fix and reboot or whatever you have to do to make it all work again properly.
Thanks

There's a large discrepancy in the PN between the number of DCLP records appearing under Collection in litpap and those in papyri.info. The former shows 14636 (see here) and the latter 10211 (see here) records; you’ll notice that the first 4 hits on the litpap page are absent from the papyinfo page. What is related, if you navigate to P.Herc. in the Series menu, you’ll find that litpap displays 232 hits (litpap p.herc.) whereas papyinfo shows 67 (http://www.papyri.info/search?DATE_MODE=LOOSE&DOCS_PER_PAGE=15&SERIES=dclp%3Ap.herc). As far as I can tell, files are not actually missing from papyri.info, they’re just not appearing in the PN.

https://github.com/papyri/navigator/blob/master/pn-xslt/Rakefile

Currently, we'll wind up with whatever happens to be on EpiDoc SVN trunk. So it's impossible to know from the code what's running in prod. Ideally, we should lock SoSOL to the same revision (so, either lock PN back to SoSOL's revision or update SoSOL's revision): https://github.com/sosol/sosol/blob/master/config/externals.yml

Would you please reindex again, Hugh.
In the last three days work that has been done has not be reflected in the browse version of the texts. E.g.
https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/p.cair.zen/p.cair.zen.3/p.cair.zen.3.59377.xml
was changed but is not visible in
http://papyri.info/ddbdp/p.cair.zen;3;59377

Sync also does not seem to be performing correctly. It did so briefly last week when you fixed it. It seems, however, to have struck difficulties again.

Would you please have a look and try to fix it.

Many thanks

James

Hello, Hugh, would you please take a look at the following and see if you can fix it, or let me know what has to be done to fix it.

http://papyri.info/hgv/697591/source
works fine
http://papyri.info/hgv/697591/
produces
HTTP Status 404 -

type Status report

message

description The requested resource () is not available.
Apache Tomcat/7.0.16

The file
https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/p.koeln/p.koeln.14/p.koeln.14.584.xml
looks fine to me as far as idnos is concerned
the matching file
https://github.com/papyri/idp.data/blob/master/HGV_meta_EpiDoc/HGV698/697591.xml
also looks good.

Why does
http://papyri.info/ddbdp/p.koeln;14;584
and
http://papyri.info/hgv/697591
produce

HTTP Status 404 -

type Status report

message

description The requested resource () is not available.

?? strange ??

I'm getting different search results for the same search string in papyri.info and litpap.info.

Entering γραμμ ερμην in litpap.info yields 64 results

http://litpap.info/search?STRING=(%CE%B3%CF%81%CE%B1%CE%BC%CE%BC+%CE%B5%CF%81%CE%BC%CE%B7%CE%BD)&no_caps=on&no_marks=on&target=text&DATE_MODE=LOOSE&DOCS_PER_PAGE=15

whereas γραμμ AND ερμην in papyri.info yields only 50

http://www.papyri.info/search?STRING=(%CE%B3%CF%81%CE%B1%CE%BC%CE%BC)%C2%A4(AND+%CE%B5%CF%81%CE%BC%CE%B7%CE%BD)&no_caps=on&no_marks=on&target=text&DATE_MODE=LOOSE&DOCS_PER_PAGE=15

Interestingly, the papyri.info search doesn’t catch this, where ερμην is in the apparatus.

http://litpap.info/ddbdp/bgu;16;2594/?q=SUBSTRING:(%CE%B3%CF%81%CE%B1%CE%BC%CE%BC+%CE%B5%CF%81%CE%BC%CE%B7%CE%BD)&rows=3&start=2&fl=id%2Ctitle&fq=transcription_ngram_ia%3A%28%CE%B3%CF%81%CE%B1%CE%BC%CE%BC+%CE%B5%CF%81%CE%BC%CE%B7%CE%BD%29&sort=series+asc%2Cvolume+asc%2Citem+asc&p=3&t=63

There are several display problems in Biblio: journal and volume no. are not being surfaced; article titles are being duplicated (one in quotation marks, the other in italics). Here's an example

http://www.papyri.info/biblio/95357?q=keyes

Hello Hugh. Please do a reindex of idp.data.
Would you please look especially at
https://github.com/papyri/idp.data/tree/master/Biblio/96
I suspect they have been missed in previous reindexing. An example:
https://github.com/papyri/idp.data/blob/master/Biblio/96/95026.xml
A search for "Spiegelberg" in
http://papyri.info/bibliosearch
offers no return. A search for "Siegesfeier" also returns nothing.
A special reindex of this folder may be necessary.

Would you also please look at #22. It would be great to have it on display.

Hi,
First of all, thank you for opening data to github, it is a pioneering project and i really hope to see more from it. I was trying to harvest some texts from papyri.info for research purposes. I have noticed that though the xml schema definition stays the same, 8.16 epidoc, the information encoded inside the document changes place. For example, here the date of the document is under head which is a child of the body tag under the text tag, whereas in here there is no date at all in the transcription file, but the date of the document is found in another file here under origDate tag.

Is there an api where we can simply enter the terms we have used in the navigator to harvest the resulting text with the information presented in the search page: date, place, line number, etc. I have noticed that you are using SOLR, the eagle project also uses it and there there is an entry point for interacting directly with SOLR for making queries. Maybe there is something similar for papyri.info too, but i've failed to find it.
I've also noticed that the sections of the project is quite well documented, which made me wonder if there is a guide for developpers for covering simple interactions such as i've inquired.

Thanks again for the project.

Apparatus does not appear in http://dev.papyri.info/dclp/128922.
When I view this is looks like:

If one compares http://litpap.info/dclp/128922
One sees:

None of the following lead to a display:

http://papyri.info/ddbdp/p.lips;1;34dupl
http://papyri.info/ddbdp/p.lips;1;35
http://papyri.info/ddbdp/chla;12;524

http://papyri.info/hgv/22345
http://papyri.info/hgv/22346

Here are the details

https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/p.lips/p.lips.1/p.lips.1.34dupl.xml#L14-L18

    <idno type="filename">p.lips.1.34dupl</idno>
        <idno type="ddb-perseus-style">0153;1;34dupl</idno>
        <idno type="ddb-hybrid">p.lips;1;34dupl</idno>
        <idno type="HGV">22345</idno>
        <idno type="TM">22345</idno>       

https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/p.lips/p.lips.1/p.lips.1.34dupl.xml#L55

        <ref n="chla;12;524" type="reprint-in">dupl=Ch.L.A. 12,524</ref>

https://github.com/papyri/idp.data/blob/master/HGV_meta_EpiDoc/HGV23/22345.xml#L10-L14

        <idno type="filename">22345</idno>
        <idno type="TM">22345</idno>
        <idno type="ddb-perseus-style">0153;1;34dupl</idno>
        <idno type="ddb-filename">p.lips.1.34dupl</idno>
        <idno type="ddb-hybrid">p.lips;1;34dupl</idno>

https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/chla/chla.12/chla.12.524.xml#L14-L18

        <idno type="filename">chla.12.524</idno>
        <idno type="ddb-perseus-style">0279;12;524</idno>
        <idno type="ddb-hybrid">chla;12;524</idno>
        <idno type="HGV">22346</idno>
        <idno type="TM">22346</idno>

https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/chla/chla.12/chla.12.524.xml#L61-L62

        <ref n="p.lips;1;35" type="reprint-from">P.Lips. 1,35</ref>
        <ref n="p.lips;;34dupl" type="reprint-in">dupl=P.Lips. 34dupl</ref>

https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/p.lips/p.lips.1/p.lips.1.35.xml#L14-L18

        <idno type="filename">p.lips.1.35</idno>
        <idno type="ddb-perseus-style">0153;1;35</idno>
        <idno type="ddb-hybrid">p.lips;1;35</idno>
        <idno type="HGV">22346</idno>
        <idno type="TM">22346</idno>

https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/p.lips/p.lips.1/p.lips.1.35.xml#L47-L50

        <ref type="reprint-from">dupl=P.Lips. 34dupl</ref>
        <ref n="chla;12;524" type="reprint-in">Ch.L.A. 12,524</ref>
     </head>
     <div xml:lang="grc" type="edition" xml:space="preserve"><ab/></div>

https://github.com/papyri/idp.data/blob/master/HGV_meta_EpiDoc/HGV23/22346.xml#L10-L14

        <idno type="filename">22346</idno>
        <idno type="TM">22346</idno>
        <idno type="ddb-perseus-style">0153;1;35</idno>
        <idno type="ddb-filename">p.lips.1.35</idno>
        <idno type="ddb-hybrid">p.lips;1;35</idno>

Hugh,

would you please merge the following two commits into
https://github.com/papyri/idp.data/tree/master/HGV_meta_EpiDoc

they are:
papyri/idp.data@4f2476e
and
papyri/idp.data@5af8eef

found at:
https://github.com/papyri/idp.data/commits/xwalk

These provide "metadata" for P.Genova V and P.Köln XIV. Since both P.Genova and P.Köln already exist as series, a new volume should appear in
http://papyri.info/browse/hgv/PUG (P.Genova)
and
http://papyri.info/browse/hgv/P.Koln

I would assume.
Would you also do a full re-index in order to catch up with #7, because papyri.info is still linking back to an old and now defunct defunct link.

In the search results, under the Translations column, it shows 'None' even if there is a translation.

Hello Hugh, I had what looked like a time out on finalization. You can see the details in
papyri/sosol#31
Somehow or other this file
http://papyri.info/editor/publications/50138
has not been picked up by sync and thus not incorporated into the master files.
Would you please have a look and try to fix it in such a way to ensure the
p.cair.mich.2.12f_r.xml
is included in
https://github.com/papyri/idp.data/tree/master/DDB_EpiDoc_XML/p.cair.mich/p.cair.mich.2
and is displayed next to the metadata at
http://papyri.info/hgv/397533

Thanks

As of today I have managed to rename all the files which ended ...dgtl. There are all now in:
https://github.com/papyri/idp.data/tree/master/DDB_EpiDoc_XML/ddbdp
Would you please do a reindex so that all the realignment can take place and so that old alignments disappear. Only
http://papyri.info/ddbdp/ddbdp;2013;1
displays properly
http://papyri.info/ddbdp/ddbdp;2014;1
http://papyri.info/ddbdp/ddbdp;2015;1
http://papyri.info/ddbdp/ddbdp;2015;2
http://papyri.info/ddbdp/ddbdp;2015;3
all display
HTTP Status 404 -

type Status report

message

description The requested resource () is not available.
Apache Tomcat/7.0.16

Building blocks are
http://www.apd.gwi.uni-muenchen.de:8080/apd/show2.jsp?papname=
Followed by the content of the idno type=”APD” tag
Grohmann_Apercu_p_41
e.g.
https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/sb/sb.6/sb.6.9576.xml#L19

would give a link to:
http://www.apd.gwi.uni-muenchen.de:8080/apd/show2.jsp?papname=Grohmann_Apercu_p_41

To be surfaced under “related sources” like GLRT
E.g.
http://papyri.info/ddbdp/bgu;1;39

Soon (October 2017), Chrome (version 62) will start showing warnings for all form inputs on non-HTTPS sites: http://www.zdnet.com/article/google-tightens-noose-on-http-chrome-to-stick-not-secure-on-pages-with-search-fields/

LetsEncrypt might be the way to go with this, though that assumes we can successfully configure automatic renewal (see https://letsencrypt.org/2015/11/09/why-90-days.html).

I get expected hits searching for words in p.petr;3;42

http://papyri.info/search?STRING1=%CF%80%CE%BB%CE%B5%CE%BF%CE%BD%CE%B1%CE%BA%CE%B9%CF%83&target1=TEXT&no_caps1=on&no_marks1=on&page=3

but the html page does not display

http://papyri.info/ddbdp/p.petr;3;42/?q=SUBSTRING:(%CF%80%CE%BB%CE%B5%CE%BF%CE%BD%CE%B1%CE%BA%CE%B9%CF%83)&rows=3&start=41&fl=id%2Ctitle&fq=transcription_ngram_ia%3A%28%CF%80%CE%BB%CE%B5%CE%BF%CE%BD%CE%B1%CE%BA%CE%B9%CF%83%29&sort=series+asc%2Cvolume+asc%2Citem+asc&p=42&t=52

Instead, I find

HTTP Status 404 -

type Status report

message

description The requested resource () is not available.
Apache Tomcat/7.0.16

See: http://papyri.info/ddbdp/p.lond;1;113,12D

The DDbDP transcription is displayed twice, for some reason.

Browsing by HGV
http://papyri.info/browse/hgv/
then to series and volume we get the following
http://papyri.info/search?SERIES=P.Oxy.&VOLUME=83
where only those numbers which already have a relevant ddbdp file are displayed.

Here we would like to see a list of all P.Oxy. 83 numbers for which there is no text added. This is the way most people locate files in order to add the relevant Greek / Latin / Coptic text.

Would you please make it work again in that way.

First of all what do I mean by "Header"?
An example from existing papyri.info.
http://papyri.info/ddbdp/p.mich;8;465
The bit below the Browse (in grey) section

that is the string
p.mich.8.465 = HGV P.Mich. 8 465 = Trismegistos 17239 = oxford-ipap.apis.1613 = michigan.apis.2580
It is, of course, the same in dev
http://dev.papyri.info/ddbdp/p.mich;8;465
That is what I am calling a "Header"

I have found one category of "Header" in dev DCLP that is at present displayed in a way that we would like to change please. Described below.

Hugh,

would you please merge the following commits into
https://github.com/papyri/idp.data/tree/master/HGV_meta_EpiDoc

papyri/idp.data@ae81a66
and
papyri/idp.data@75aa5ec (probably not necessary as it is overwritten by the one above)
and
papyri/idp.data@9fd6264
and
papyri/idp.data@5ce0b22

found at:
https://github.com/papyri/idp.data/commits/xwalk

These provide "metadata" for O.Bankes and P.Daris, both of which are new series. Would you please make the relevant changes to
https://github.com/papyri/idp.data/blob/master/RDF/collection.rdf
as well as making them both appear at the relevant position in
http://papyri.info/browse/ddbdp/
and
http://papyri.info/browse/hgv/

Then please reindex. There seems to have been funny stuff going on today with github (is it part of the reported DDoS attacks?).
Reindex should also make p.cair.arab. appear I would hope.

Anyway that would be stupendous if you could get this done for next week.

Many thanks

Using the same definition of "Header" as in #41, there is a further little improvement that would be nice.

http://dev.papyri.info/dclp/65294
O. Strasb. . 1 807 = Trismegistos 65294 = LDAB 6538
differs from
http://litpap.info/dclp/65294
O. Strasb. . 1 807 = Trismegistos 65294 = LDAB 6538 = HGV O.Strasb. 1 807 = Trismegistos 65294

Hugh,

would you please merge the following two commits into
https://github.com/papyri/idp.data/tree/master/HGV_meta_EpiDoc

they are:
papyri/idp.data@c160cff
and
papyri/idp.data@524d77c

found at:
https://github.com/papyri/idp.data/commits/xwalk

These provide "metadata" for SB XXVIII; P.Coles; P.Tebt.Pad. I. Since SB already exista as series, a new volume should appear in:
http://papyri.info/browse/hgv/SB

Neither P.Coles nor P.Tebt.Pad. I exist so would you please do the necessary so that they are included in:
http://papyri.info/browse/hgv/

At
https://github.com/papyri/idp.data/blob/master/RDF/collection.rdf#L1328-L1333
I added the relevant information in
https://github.com/papyri/idp.data/tree/master/RDF

Hugh,

would you please merge the following commits into
https://github.com/papyri/idp.data/tree/master/HGV_meta_EpiDoc

papyri/idp.data@1904f21
and
papyri/idp.data@b5bd07d

found at:
https://github.com/papyri/idp.data/commits/xwalk

These provide "metadata" for O.Ber. III.

Then please reindex.

It would be stupendous if you could get this done for next week (so that there are files which the students in the London EpiDoc training course can enter texts for).

Many thanks

The XML of the following line is correct:
https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/p.oxy/p.oxy.47/p.oxy.47.3338.xml#L79
in particular
<expan>αἶγ<ex>ας</ex></expan>
is correctly encoded. It is preceded by whitespace and before that
<num value="110">ρ<supplied reason="lost">ι</supplied></num>

When this is displayed in preview in the editor and in the navigator what we see in line 7 is:
ρ[ι] ἶγ(ας)
http://papyri.info/ddbdp/p.oxy;47;3338

In other words the initial alpha is missing.

I assume this must be related to an XSLT problem. It should be fixed. There have been some submissions to the board with attempts to correct this. It is usually the case that the underlying XML is correct.

First of all the new reloading does seem to have solved the problems mentioned in #36

My question was: show me all files where Homerus is the author and there is a text div with content.

Actions taken.
Navigate via authors
http://dev.papyri.info/authors
http://dev.papyri.info/authors#H
http://dev.papyri.info/dispatch/search?AUTHOR=Homerus
nice 1689 hits
now using (at the bottom)
Has Transciptions and choosing (true 37) [which seems about right]
I arrive at
http://dev.papyri.info/dispatch/search?TRANSC=true&DATE_MODE=LOOSE&DOCS_PER_PAGE=15
which displays ALL texts across DDB and DCLP which have a transcription.

Would be nice to arrive at the 37.

http://papyri.info/#
enter 8988
leads to http://papyri.info/ddbdp/bgu;1;224dupl
So fine. For ddbdp/hgv files things work well.

Back to the same search interface http://papyri.info/#
enter 64248
I get no hit but see this

So I decided to look for that number another way.
http://papyri.info/browse/dclp/
http://papyri.info/search?&COLLECTION=dclp&SERIES=tm
now I enter 64248 into the ID # box

No hits and I see this

but I know that this TM number is in the system
http://papyri.info/dclp/64248

So searching for a TM number that is anchored in the DCLP world is not functioning as we would like it to.

http://dev.papyri.info/
now call up TM number search
type in 64127 (TM number for a DCLP record) hit enter button.
Leads to
Not Found
The requested URL /dclp/64127 was not found on this server.

Apache/2.2.15 (Scientific Linux) Server at papyri.info Port 80

this pushes us through to
papyri.info/dclp/64127 NOT dev.papyri.info

Does that mean that when this goes live it WILL in fact work? See below.

Searches involving THEN show a hit. But if you click on the hit it returns an HTTP Status 400 – Bad Request

So

Then

Which uses the URL:

http://papyri.info/search?STRING=(υμων+THEN+δεσποτων)~1chars&no_caps=on&no_marks=on&target=text&DATE_MODE=LOOSE&DOCS_PER_PAGE=15

returns

where the URL is

http://papyri.info/ddbdp/p.grenf;1;60?rows=2&start=0&fl=id,title&fq=untokenized_ia:/@υμων.{1,1}δεσποτων@/&p=0&t=0

@ http://papyri.info/ddbdp/bgu;16;2629
In line 16 of this text, there is the word ε̣ἶ̣ναι. It appears correctly in the git file:
<unclear>εἶ</unclear>ναι
https://github.com/papyri/idp.data/blob/master/DDB_EpiDoc_XML/bgu/bgu.16/bgu.16.2629.xml#L106
but the HTML display leaves out the soft breathing mark, ε̣ῖ̣ναι(*).

ματέως ἄγνοι̣α̣ν̣ ε̣ῖ̣ναι(*), τὸ πρότερον φάσκων μη-

I called up papyri.info and have six tabs open: papyri.info entry page, PN search page (hit the Search data button), home user_dashboard, DDB board, HGV board, DCLP board.

This is what they look like:

Papyri.info | PN Search | DCLP | DCLP | DCLP | DCLP

We do not want DCLP appearing here. I have forgotten what it used to be when one was in the boards before DCLP was part of the system. There might be a nice argument for displaying DCLP for the DCLP board, DDB for the DDB board, HGV for the HGV board, APIS for all the APIS boards, Transl for the Translation board.

For an editor who is working that would be very helpful.

If, however, that is more work, then please replace DCLP with Papyri.info or whatever it used to be.

This is about the filter possibilities in "Collection".
I shall use as an example the search taken from
#47
Substring: γραμμ AND ερμην
Here it is
http://papyri.info/search?STRING=(γραμμ)%C2%A4(AND+ερμην)&no_caps=on&no_marks=on&target=text&DATE_MODE=LOOSE&DOCS_PER_PAGE=15

The first two hits as well as the display of what you have searched for is like this

Should probably be in the CSS for both Navigator and Editor. May want to only download/use if no preferred fonts are installed locally: http://stackoverflow.com/questions/14456582/css-font-face-only-download-when-font-is-non-existent

Selecting a collection in the drop-down menu automatically generates the value "n.a." in the volume box. This make's it impossible to apply an additional, 'volume' filter.

Here's a screenshot:

https://user-images.githubusercontent.com/6115249/58172756-b9c44900-7c99-11e9-83dd-cda3939373f2.png

Lots of these have been added, and the original biblio XSLT just doesn't pick up the <ptr> targets. See e.g. https://github.com/papyri/idp.data/blob/master/Biblio/63/62455.xml.