I don't think anyone brought this up , and I would think the reason is because of the loss of information involved. But seeing as how Github refuses to deal with wt5 file attachments, I thought it useful to promote a discussion on the possibility of taking the text dump of wt.data from translate_to_txt and re-encapsulating it into a Data object.
We know it to be lossy, but it seems that this procedure is a good way to disseminate data.
A thought was to append some form of information indicating that the re-encapsulated object was "stripped" of information via this process such that future users would know that any future wt5 files are not the originals.
@kameyer226 , rather than this approach, here are a couple alternative approaches for when you want to discuss specific errors working up data:
Script a Data object that reproduces the issue. Debugging is easiest when you provide a minimal working example (i.e. you probably do not need the exact .wt5 file you are working up to reproduce the issue). Personally, I find that by trying to reproduce my issues with a self-constructed Data object, I often figure out what the issue is.
If the former approach doesn't work, host the data on the cloud (e.g. Google drive, osf) and provide the data via a link.
Hello,
I don't think anyone brought this up , and I would think the reason is because of the loss of information involved. But seeing as how Github refuses to deal with wt5 file attachments, I thought it useful to promote a discussion on the possibility of taking the text dump of wt.data from
translate_to_txt
and re-encapsulating it into aData
object.We know it to be lossy, but it seems that this procedure is a good way to disseminate data.
A thought was to append some form of information indicating that the re-encapsulated object was "stripped" of information via this process such that future users would know that any future wt5 files are not the originals.