Upgrade StorageWould a GitLab.com translator be generalisable for self-hosted C/EEs?
Hello!
There is already a [GitHub translator](https://github.com/zotero/translators/blob/master/Github.js), but none for GitLab.com. This leads to the a) obvious question whether someone will eventually build one for repositories hosted there. However, more interesting would IMHO be whether b) all the [self-hosted GitLab Community or Enterprise Editions](https://about.gitlab.com/products/) could be supported by a single translator?
Given [GitLab's strategic goal](https://about.gitlab.com/strategy/#sequence) of "become[ing] the most popular collaboration tool for knowledge workers in any industry." we can IMHO expect the necessity for a) _and_ b) to increase.
Therefore (and I have no experience with writing translators, so this is just from 30min looking through the [GitHub-related issues & PRs](https://github.com/zotero/translators/)): Can [`detectWeb`](https://www.zotero.org/support/dev/translators/coding#web_translators) operate on common properties of the `document` rather than only `target`-ing the URL with a reg-ex? The latter case maybe have a slim chance of being generalisable, if institutions stuck to a convention like using the subdomain "git" every time.
Thanks for any input here :-) It would be great if this discussion could pool some advice for interested developers to start working on this potentially hard nut.
There is already a [GitHub translator](https://github.com/zotero/translators/blob/master/Github.js), but none for GitLab.com. This leads to the a) obvious question whether someone will eventually build one for repositories hosted there. However, more interesting would IMHO be whether b) all the [self-hosted GitLab Community or Enterprise Editions](https://about.gitlab.com/products/) could be supported by a single translator?
Given [GitLab's strategic goal](https://about.gitlab.com/strategy/#sequence) of "become[ing] the most popular collaboration tool for knowledge workers in any industry." we can IMHO expect the necessity for a) _and_ b) to increase.
Therefore (and I have no experience with writing translators, so this is just from 30min looking through the [GitHub-related issues & PRs](https://github.com/zotero/translators/)): Can [`detectWeb`](https://www.zotero.org/support/dev/translators/coding#web_translators) operate on common properties of the `document` rather than only `target`-ing the URL with a reg-ex? The latter case maybe have a slim chance of being generalisable, if institutions stuck to a convention like using the subdomain "git" every time.
Thanks for any input here :-) It would be great if this discussion could pool some advice for interested developers to start working on this potentially hard nut.
-
adamsmithdetectWeb is URL independent, but the target isn't and we are very restrictive about the translators that run detect on every URL (since, well, they run detect on every URL, which means they directly browser speed). There are currently 4 (unAPI, DOI, COinS, Embedded Metadata) and we're unlikely to add more.
-
zuphilipIt is possible to tackle this on the other side: If GitLab would provide more metadata, COinS or an unAPI interface, then these Zotero translator could provide bibliographic information.