Issues?

[frivoal]

The way this is currently being proposed, with images being filled as (labeled) issues makes it very easy to submit the images, and gives us a simple UI for sorting through things, both of which are really good features. On the other hand:

• only people with write access to the repo can set labels, which presumably exclude most submitters
• We cannot provide any view not supported by github issues, for example views with thumbnails.
• everything lives in github's databases, so we depend on them for hosting.

An alternative would be to take in the samples via pull request, and ask the submitter to provide the image and a metadata file in an agreed format with the relevant tags and possibly some descriptions. We could use that in a static site generator to create any kind of view we wanted. A big downside is that it would put quite a bit of overhead into submitting new images. Also, we would have to rebuild the search feature. That can be done without too much work on a static site (see here for an example: http://jekyll.tips/jekyll-casts/jekyll-search-using-lunr-js/), but we'd still have to do it. We'd also need to add some system for per-file discussion, which could be done with something like discuss.

A simple meta-data file, well suited for usage with the jekyll static site generated that github pages uses, could be something like this: From issue https://github.com/w3c/type-samples/issues/12:

---
title: Arabic, tatweel based justification
img: /imgs/123456789.jpg
langs: [ar]
scripts: [Arab]
tags: [justification]
medium: book
source: Asharq al Awsat, p1, 12 Dec 1994
---
Various examples of lines being stretched to fit justified columns
using simple baseline extensions.

From issue https://github.com/w3c/type-samples/issues/11:

---
title: Arabic, bilingual sign justification
img: /imgs/0987654321.jpg
langs: [ar, en]
scripts: [Arab, Latn]
tags: [justification]
medium: signage
source: Oman, Muscat
---
The arabic text is stretched to be the same width as the latin text it corresponds to.

If this sounds interesting, I'm willing to give a shot at building a prototype/alpha version of that (and to maintain it if that's convincing enough that we're willing to adopt it).

[r12a]

Thanks @frivoal ! First thoughts...

If we roll our own solution, i think it would need to be easy to install simply for people who want to use it locally - without them having to install packages or libraries first. I'm mostly unsure how the comment management would work. I suspect we'd miss things too, such as backlinks when someone refers to a picture in a discussion in another repo.

I very much agree that the images would be best stored in the repo via pull requests, so that you could clone your own copy locally. My early experiments involved uploading a picture and short textual metadata file. This involved a rather messy second step of creating the issue after the upload, so that one can filter and add comments. I found it waaay easier to work with issues directly, for uploading pictures and formatting the text, and eventually switched to that. Btw, using PRs also limits contributions to those people who are comfortable using GitHub - although i suppose it's possible that that will be an advantage too.

It's a shame that the two appproaches don't quite meet in github.

I wondered whether perhaps we could do something using the github API. Filtering is easy. I already have a simple HTML+javascript page that filters and presents issue data at http://w3c.github.io/i18n-activity/reviews/. If the API allows us to extract pictures from issues, that might be an easy way to create a search interface pointing to issues. I wonder though whether it's also possible to use the API to copy pictures (and maybe metadata) from issues into files in github directories....?

[frivoal]

I'm mostly unsure how the comment management would work.

Most likely, it would be some databased-backed js-based comment system, similar to disqus That's my least favorite part of my proposal, so I'll think to see if I can do something different / better.

I suspect we'd miss things too, such as backlinks when someone refers to a picture in a discussion in another repo.

That is indeed something I would not be able to reproduce.

This involved a rather messy second step of creating the issue after the upload, so that one can filter and add comments.

My solution would not need an issue for either. Filtering would be entirely built into the site, and comments would be as discussed above. Either way, no need for a second step.

If we roll our own solution, i think it would need to be easy to install simply for people who want to use it locally - without them having to install packages or libraries first.

Working offline is a goal for me as well, so I'd be careful about that. As for dependencies, I was not thinking of 0, but I was thinking of something very lightweight:

git clone https://github.com/w3c/type-samples.git
cd type-samples
bundle install && bundle exec jekyll server

would be all you need to get a local web server serving the site on localhost:4000

I wondered whether perhaps we could do something using the github API.

That could work too, but I know much less about that.

[r12a]

@frivoal I quickly adapted one of my previous pages to give a visual index at https://w3c.github.io/type-samples. I think that combining this with some very simple rules for how to add minimal metadata to the issue one raises gets us largely what is needed.

I adapted the content of most of the issues. The issue title uses the pattern:

<script-code> <lang-code> <medium-tag> <feature-tag(s)>

This is mostly for my benefit, since i need to supply the labels, and that gives me the information i need to do that. But it also produces a reasonable title too.

Inside the issue you have

<picture>
---
img: <image-name>  [useful for looking up an image in the directory]
tag: <feature-tag> <short-description>
[possibly more tags]
source: <source info or link>
---

One can add notes after this, if desired, and possibly a transcription to make it easy to develop tests.

I also realised that it's actually trivial to get the images into the directory structure. I just need to have the issue open in a window and a finder window open alongside, then drag and drop the pic into the directory. When i'm done processing a few issues, i just push the local files to the repo.

I'll see how things go with this, for a while, since it seems it may be adequate and it allows us to leverage all the github goodness with minimal effort.

[r12a]

@tomerm given the above, i'd like to adapt the Hebew issues you have created to suit the new format. However, i think some of your issues could be carried as is to https://github.com/w3c/hlreq to form the basis of some initial drafts for the hlreq document. If you're ok with that, i can port the issues to the hlreq repo and then reformat them in this repo tomorrow.

[tomerm]

@r12a thanks for taking care of this. I am OK with suggested action plan.