cwrc / CWRC-WriterBase

The base class from which to create a CWRC-Writer XML editor.
GNU General Public License v2.0
14 stars 3 forks source link

Add translation button and mini editor for EpiDoc documents #123

Open ilovan opened 5 years ago

ilovan commented 5 years ago

Mockups at https://balsamiq.cloud/s7b9f6j/pofq7bg/r7F10 (as of September 2019):

Git-Writer - translation

ilovan commented 5 years ago

Make paragraph selected by default and add both div and p tags, as shown at http://www.stoa.org/epidoc/gl/latest/supp-translation.html If "ab" selected by user, add div and ab. Language dropdown - display full language name but add two letter code (https://www.loc.gov/standards/iso639-2/php/code_list.php) in the xml:lang attribute value.

ilovan commented 5 years ago

@JonPrag, can you please review and let us know if you have any thoughts about this?

JonPrag commented 5 years ago

This looks right to me, although we don't use <ab> ourselves in the translation division. The translation <div> goes immediately after the text <div> (which themselves can be multiple. In I.Sicily we keep the translation element very simple and currently do not incorporate any mark-up on the translation. In future we might change that, but since I'm hoping to work with school students on the translations, I have no immediate intention of doing so. That means that there will not be any markup beyond the all-embracing <p> element. We simply repeat the entire translation <div> for each separate language translation. The one addition that i think I would want to allow for is what is described in the Epidoc guidelines, as you pointed to above (http://www.stoa.org/epidoc/gl/latest/supp-translation.html), which is the facility to put <div type="textpart"> within the overall translation div (if we were to allow this, then the simple, non-formal attribute of @n=(number or letter of fragment/column) would be sufficient at this point). But the total number of instances of this are small, so I could deal with this manually as editor outside of the tagger perfectly easily also, so don't include if too complicating.

I do, however, have one key request here, which I forgot before, which is the ability to add @resp on the translation div. I am keen generally to ensure that this information is recorded within the file whenever possible for key elements such as translation, not least because these will often be undertaken by other people. At present, this is done by adding @resp="#INITIALS", which in turn points to the relevant <respStmnt> element up in the header, which has the general form: image I'm imagining it will get too complicated to enable this also? But could we at least make visible the option to add the @resp attribute with their initials (I could then do the rest externally if need be), even if we can't also include adding in a full <respStmnt> (if we can, this would need a couple of dropdowns / input fields which would need to ask for their name, automatically assign them the resp of 'translation', and ask for their ORCID in case they have one). I imagine this might be doable automagically from the GitHub account information, but that's probably even less straightforward... Sorry to complicate...

SusanBrown commented 5 years ago

Another matter we need to consider is the LOD representation of the markup. Jonathan, we're using the Web Annotation Data Model to generate the RDF. Not sure if you're interested in this side of things, but if you are would love your input if you have an interest. Am sharing the Google doc that lays out what we're doing with other tags with you.

ilovan commented 5 years ago

Re resp. attribute:

We can easily add a check mark on the form that would read "Add responsibility" and have the user checking on that automatically add the GitHub UserID of the current user to the resp attribute value (this would match what we are doing in general with the LOD annotations where the information is collected for each annotation). I would hesitate to go the full way with the respStatement added to the Header, as this seems like a project-specific practice.

Re the other attributes, they would all be available under "Markup options", provided they are supported by the current schema.

JonPrag commented 5 years ago

That sounds like it would be sufficient to be going on with.

Many thanks Jonathan

From: Mihaela Ilovan notifications@github.com Sent: 19 September 2019 16:33 To: cwrc/CWRC-WriterBase CWRC-WriterBase@noreply.github.com Cc: Jonathan Prag jonathan.prag@merton.ox.ac.uk; Mention mention@noreply.github.com Subject: Re: [cwrc/CWRC-WriterBase] Add translation button and mini editor for EpiDoc documents (#123)

Re resp. attribute:

We can easily add a check mark on the form that would read "Add responsibility" and have the user checking on that automatically add the GitHub UserID of the current user to the resp attribute value (this would match what we are doing in general with the LOD annotations where the information is collected for each annotation). I would hesitate to go the full way with the respStatement added to the Header, as this seems like a project-specific practice.

Re the other attributes, they would all be available under "Markup options", provided they are supported by the current schema.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/cwrc/CWRC-WriterBase/issues/123?email_source=notifications&email_token=AF7LEQQXGVYNJHVBDTPV4OTQKOLULA5CNFSM4GKXCZWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7D4R2Q#issuecomment-533186794, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF7LEQVJ636CQWOFXWFNA63QKOLULANCNFSM4GKXCZWA.

ajmacdonald commented 5 years ago

https://github.com/cwrc/CWRC-WriterBase/commit/38c73e8fcce5a564d976da3d5b123180b4e6733e

ajmacdonald commented 5 years ago

I've updated https://dev-cwrc-writer.cwrc.ca/ with an initial implementation.

ilovan commented 4 years ago

confirmed on dev-cwrc-writer