Skip to content
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

Terminology of ruby #21

Closed
himorin opened this issue May 11, 2020 · 7 comments
Closed

Terminology of ruby #21

himorin opened this issue May 11, 2020 · 7 comments

Comments

@himorin
Copy link
Contributor

himorin commented May 11, 2020

In current simple-ruby, "ruby string" (partly "ruby characters") and "base characters" / "base character string" / "ruby base xxxx" are used.
In JLReq, "ruby character(s)" and "base character" (along with "non-base character") are used.

We might be better to unit these.

@xfq
Copy link
Member

xfq commented May 12, 2020

FWIW, clreq uses "annotation text" and "base text".

@himorin
Copy link
Contributor Author

himorin commented May 28, 2020

@kidayasuo any suggestion?

@kidayasuo
Copy link
Contributor

kidayasuo commented May 28, 2020

“ruby something” and “(ruby) base something” where something = string or text or characters?

Since the name of the feature is “ruby” using it feels natural. It would also avoid possible misunderstandings.

As for the "something" part, as they are short, typically one word or one compound word, “string” would be a good choice. To me “text” is at least a sentence. “characters” can mean a collection of characters like “fullwidth characters” v.s. “character string”, i.e. a bit ambiguous. So, however I do not have a strong opinion, I would vote for “string”.

@himorin
Copy link
Contributor Author

himorin commented May 29, 2020

I'd vote for "ruby string" and "ruby base string", too.

@himorin himorin added this to the 202006-release milestone May 29, 2020
@r12a
Copy link
Contributor

r12a commented Jun 2, 2020

The document contained many instances such as "When one of the ruby strings is longer than the base character string". This is incorrect stated, since most (all?) ruby strings will be longer than the base string. For example, はたけ is a string of 3 characters, while its base string, 畑, is only 1 character.

In the edits to the translation i changed the following:

  • 'ruby string' to 'ruby annotation'
  • 'is longer than' to 'is wider than'
  • 'the base character string' to 'its base text'

So the sentence becomes "When one of the ruby annotations is wider than its base text", which is much simpler, clearer, and more accurate.

This terminology fits better with the existing documentation in our articles, but is also more accurate. Strings are usually things that are measured in code points internally, but we are talking in this document about two visually-realised entities and their relationship. 'Longer than' is ambiguous, especially when talking about strings, because it could relate to the number of code points: actually its the visual width when typeset that is the determining factor in these rules.

@r12a
Copy link
Contributor

r12a commented Jun 2, 2020

Also, 'ruby string' is ambiguous to the newcomer, who has to figure out that the term is being used to refer to the annotation part of the ruby arrangement, rather than the base+rubyText, or even the base alone. Using 'ruby annotation' makes it immediately clear what we are talking about.

Using 'base character string' causes one to wonder why the word 'character' is needed here, whereas it wasn't needed for 'ruby string'. But also 'base character string' in some places in the document doesn't clearly enough indicate that we are talking about just the base text that is associated with the annotation, and there's still the issue about the use of the word 'string'. Apart from that, it's quite a long phrase, which lowers readability of the text. Changing to 'its base text' reduces the wordiness, while clarifying that we are talking specifically about the text that is specifically associated with the annotation.

@r12a
Copy link
Contributor

r12a commented Jun 3, 2020

Closing, since this was addressed in #34

@r12a r12a closed this as completed Jun 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants