testfile to check whether it arrives in apilcs

[OliverStreiter]

No description provided.

[simonwiles]

Hi Oliver, happy new year :)

If I (or you) merge this PR the test file will be accessible on apilcs.github.io. Just wanted to point out, though, that this repo is automatically generated and so manual changes will (well, would) be overwritten if the source code for this repo (at apilcs/website) is updated and rebuilt. Not sure exactly what you want to test.

Lmk if I can help :)

[OliverStreiter]

Dear Simon, I hope that you and your family are doing well in these sometimes dark and difficult times. Quite something has happened since we have met for the last time, Hong Kong has fallen, England liberated, Scotland confined, the EU-border separates England and North Ireland, and the US UN-ambassador is going to come to Taiwan. Thanks for your short feedback, showing, how little I actually understand of what you have been doing... :-( Starting at the beginning..., in 2020 I had a mini-stroke/pre-stroke, a small stroke-like event, and the time before and after I have been fighting with phenomena of which I don't know which are consequences or causes, among them, sometimes, an extreme fatigue. During the summer holidays I did fieldwork after fieldwork and felt extremely well, when the semester started, I had to commute between Tainan and Kaohsiung and I had to process my fieldwork data, the fatigue returned, in addition I spend much more time in the gym and on preparing and eating healthy food. Now, in winter holidays, I am at home working from my armchair and feel better than 20 years ago. As for our journal, actually to get it from the ground, I had some new ideas, which might not be 100% compatible with what you had in mind, but might be manageable by someone less genius-like like me, and, hopefully, not to idiosyncratic so that it cannot be merged in the middle run into something more advance as what you had in mind. I'd be curious to get your feedback and ideas how this might merge with what you have done so far. My simple ideas are as follows: The central format for the editing of articles and for the compilation of presentation formats are a) jupyter notebook (edited from github at later stages of the editing process) b) author-specific csv/json-files, such as numbers of speakers under 20 per language, or the import of rusty nails in a certain period, for which we might help the author to create standard graphs. These data are not our central concern c) journal-specific files in journal-specific csv/json-formats we have to agree upon, or 'standard' formats such as shape, etc for place names, people, journeys, ... which we use in the creation of maps, graphs, social networks, tooltip texts, external links etc in different presentation formats across different papers. These tables should be 'standardized' so that we can use the same scripts all over, again and again. We probably might also limit us on a certain number of libraries for the production of maps, social networks etc. as we might want to link papers of different authors through maps, data, social networks, etc. d) licenses for data and article e) references (in bibtex?), not sure how to link the markdown in jupyter with bibtex, through pandoc? It would also be important to maintain a journal-internal version of bibtex files to find common mistakes in bibtex files, to correct them automatically or even to offer the stock of bibtex files to authors. Presentation formats are: a) html (compiled from jupyter notebook with some, our own, modifications, to get what we want, tooltip texts, links, etc) b) pdf (jupyther to latex, applying our little modifications, to PDF) c) the jupyter notebook in a static format, if data are processed in the notebook (as shown in GitHub). Static means that the code cannot be modified d) the jupyter notebook in dynamic format, so that people can modify colors, size etc of graphs, or experiment with data sets (the same notebook shown through mybinder.org or something similar) We might restrict the access to the 'exotic' formats cascading from common to exotic. What I mean is We would show only a PDF if the HTML has no dynamic effects (no tooltip, no dynamic graphics, no data) We show the link to the static notebook only from the HTML version, in order not to scare off more traditional readers. We would show the link to the dynamic jupyter notebook only from the static notebook, telling them once you are here, you might want to try yourself. I had a short discussion with Marcus on this, his main concern was that most authors would need a training to submit papers. We thus talked about workshops we might hold aybe as appendices to small conferences, or workshops which specifically target the presentation in the journal. I personally find this a very stimulating idea, which motivates me more to continue on this path than to abandon it. Anyway, ideas, suggestions are welcome. regards, Oliver PS.: Does anyone of you remember where the C in APILCS comes from. Cultural Studies?