-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FIX] change remaining latin expressions (etc and i.e.) #628
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @Remi-Gau!
This one is more complicated than for e.g.. I am not sure that some of the changes I made "read well": suggestions welcome.
I would more often simply drop "etc." completely instead of replacing it with "and so on"
merge #626 first and then solve conflicts (my personal preference)
fine with me 👍
Not sure that the specs have a position on the sempiternal "Oxford comma" debate... But this PR might raise the question. stuck_out_tongue_closed_eyes
I use that kind of comma and feel like it helps the reading flow, but I never dove into the debate 🤷♂️ ... yet I would be a strong +1 on using it (also in this PR)
Let's wait for another reviewer (at least one) to confirm / discomfirm my opinions ... then make the changes (or not) ... then review in detail :-)
On related issue: would it make sense to "install" the github action used by the Turing way to check our content for Latin expressions to ensure we don't have to redo this in the future?
|
probably worth looking into, good idea! 👍 we'd have to clarify what else they are linting / checking, and make sure that all of these steps are (or can be) configured to our liking. If you have time and interest to do that, I'd appreciate a short report and potentially a new PR :-) |
Will mark this as ready for review to see how many conflicts we have. |
For the sake of not breaking all PRs, I commented out i.e. and etc in 11caf05. When you're ready to review, make sure you're based off of master and uncomment those. I will go through and comment on wording now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some opinions.
src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md
Outdated
Show resolved
Hide resolved
src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md
Outdated
Show resolved
Hide resolved
src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md
Outdated
Show resolved
Hide resolved
src/04-modality-specific-files/04-intracranial-electroencephalography.md
Outdated
Show resolved
Hide resolved
src/04-modality-specific-files/04-intracranial-electroencephalography.md
Outdated
Show resolved
Hide resolved
@@ -253,7 +253,7 @@ SHOULD be present: | |||
| reference | OPTIONAL | Specification of the reference (e.g., 'mastoid', 'ElectrodeName01', 'intracranial', 'CAR', 'other', 'n/a'). If the channel is not an electrode channel (e.g., a microphone channel) use `n/a`. | | |||
| group | OPTIONAL | Which group of channels (grid/strip/seeg/depth) this channel belongs to. This is relevant because one group has one cable-bundle and noise can be shared. This can be a name or number. Note that any groups specified in `_electrodes.tsv` must match those present here. | | |||
| sampling_frequency | OPTIONAL | Sampling rate of the channel in Hz. | | |||
| description | OPTIONAL | Brief free-text description of the channel, or other information of interest (e.g., position (e.g., "left lateral temporal surface", etc.). | | |||
| description | OPTIONAL | Brief free-text description of the channel, or other information of interest (e.g., position (e.g., "left lateral temporal surface")). | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it me and my sleep deprivation, but aren't these nested parenthesis hard to parse for the average human being?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you, and I just had 8 hours of sound sleep :-)
should be easy to avoid nested brackets in this case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that I had a similar thought at one point and tried switching to square brackets nested in the parentheses, but that doesn't play well with markdown (or maybe one of the other formatters that the specification uses).
d1c3be8
to
afe90cf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here are my suggestions.
src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md
Outdated
Show resolved
Hide resolved
src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md
Outdated
Show resolved
Hide resolved
src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md
Outdated
Show resolved
Hide resolved
src/04-modality-specific-files/04-intracranial-electroencephalography.md
Outdated
Show resolved
Hide resolved
Closing/reopening to re-run the RTD build. |
@Remi-Gau Do you mind if I just quickly push a few formatting changes, rather than another round of suggestions? |
The first commit was just |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy with this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: Chris Markiewicz <[email protected]>
- ignore pregh-changes.md - checks for all lating expressions
Co-authored-by: Chris Markiewicz <[email protected]>
Co-authored-by: Chris Markiewicz <[email protected]>
74088df
to
ccb817f
Compare
TO DO
for reviewers
@effigies @sappelhoff
This one is more complicated than for
e.g.
. I am not sure that some of the changes I made "read well": suggestions welcome.I will get on to the linting once we agree on the content, if that is fine with you
This will most likely create merge conflicts after #626 is merged (because it seems Latin expressions tend to live in pack and cluster), so let me know whether we should:
Not sure that the specs have a position on the sempiternal "Oxford comma" debate... But this PR might raise the question. 😝