Help talk:Glossaries/Flow

And if yes, under which form? As far as I see this is not documented so far. This might be a good idea as glossaries should help translators to make consistent translations and English being the language retained as reference.

Good point. Maybe in the "also known as" section? Or as footnotes? That can be relevant in certain cases, especially when we use some English terms as common terms (RfC, Featured article...).

I think have it as a dedicated subparagraph, additionaly to aka subparagraph would be ok.

Let's say we have :

;Term to define
:# First definition
:#:''Also known as '''other term''', '''that equivalent''', '''synonym'''''
:# Second definition
:#:''Also known as the second '''other second term''', '''that second equivalent''', '''secnod synonym'''''

Rendered as

Term to define

1. First definition

   Also known as other term, that equivalent, synonym

2. Second definition

   Also known as the second other second term, that second equivalent, second synonym

Then the Esperanto translation might be:

;Difinenda termo
:#Unua difino.
:#:''Alinomita '''alia termo''', '''tiu samvaloranto''', '''sinonimo'''''
:#:Angla: '''Term to define''', '''other term''', '''that equivalent''', '''synonym'''
:#Dua difino
:#:''Alinomita '''alia dua termo''', '''tiu dua samvaloranto''', '''dua sinonimo'''''
:#:Angla: '''Term to define'', '''''<nowiki/>''other second term'<nowiki/>'', '''that second equivalent''', '''secnod synonym'''

Rendered as:

Difinenda termo

1. Unua difino.

   Alinomita alia termo, tiu samvaloranto, sinonimo

   Angla: Term to define, other term, that equivalent, synonym

2. Dua difino

   Alinomita alia dua termo, tiu dua samvaloranto, dua sinonimo

   Angla: Term to define, other second term', that second equivalent, second synonym

I don't think English should be that prominent in translations.

How do you deal with translations when you need to update them? What about RTL languages?

Verbatim Project:Language policy "English is the main reference language, and all root pages should be named and written in English." So it's already the case that English have a prominent place in translations. What the problem you are worried about with RTL languages? What would you see as specific issue with the translation update vs any other text update? If judged relevant, the term and it's synonyms might be added in tvar, so one might right:

;Difinenda termo
:#Unua difino.
:#:''Alinomita '''alia termo''', '''tiu samvaloranto''', '''sinonimo'''''
:#:''Angla'': '''$english_term''', '''$english_synonym1''', '''$english_synonym2''', '''$english_synonym3'''

My worry about RTL languages was to have a pack of terms that wouldn't have been compatible with those languages.

Anyway, your idea is feasible. I'm still skeptical concerning bold for English, plus I don't think that's necessary to have all terms in English, just the main official one.

I still don't understand what's the issue with mixing RTL and LTR text, a concrete example would be welcome. It might be more problematic for a mainly top to bottom layout (such as in some Asian languages), but we don't provide a good support for that yet anyway, as far as I know.

For translation, it's good to have all the synonyms at hand, that ease the search. I agree that bold is a too much here, I just made some copy/paste from the current document and didn't bother changing the emphase.

There is no problem having RTL and LTR mixed, if each term is defined separately.

Ok, so are they problems remaining with the ;, :# and :#: layout/structure proposal?

I have no clue to know if it is valid.

What do you mean with valid?

If you mean, what W3C would recommand, then look at what they do in this glossary:

<dl>
  <dt class="label"><a name="abbreviationsdef" id="abbreviationsdef"></a>abréviation</dt>
    <dd><p>forme abrégée d'un mot, d'une expression ou d'un nom lorsque
      l'abréviation ne fait pas encore partie de la langue courante </p>

      <div class="note">
      <p class="prefix"><em>Note 1 : </em>ceci comprend les sigles et les
      acronymes formés à partir des initiales des mots où :</p>
      <ol class="enumar">
        <li><p><strong>les sigles</strong> sont une forme abrégée d'un nom ou
          d'une expression constituée des lettres initiales des mots ou des
          syllabes contenues dans ce nom ou cette expression.</p>

          <div class="note">
          <p class="prefix"><em>Note 1 : </em>ne sont pas définies dans
          toutes les langues. </p>
          </div>

          <div class="example">
          <p class="prefix"><em>Exemple 1 : </em>SNCF est le sigle de la
          Société nationale des chemins de fer français. </p>
          <p class="prefix"><em>Exemple 2 : </em>ESP est le sigle, en anglais,
          de <span xml:lang="en" lang="en"><em>extrasensory
          perception</em></span>, la perception extrasensorielle.</p>
          </div>
        </li>
        <li><p><strong>les acronymes</strong> sont des abréviations formées
          à partir des premières lettres ou des parties d'autres mots (dans
          un nom ou une expression) et qui peuvent être prononcés comme un
          mot. </p>

          <div class="example">
          <p class="prefix"><em>Exemple : </em>ONU est un acronyme constitué
          des premières lettres de Organisation des Nations unies.</p>
          </div>
        </li>
      </ol>
      <p class="prefix"><em>Note 2 : </em>quelques sociétés ont adopté ce
      qui constituait un sigle ou un acronyme comme nom de leur société. Dans
      un tel cas, le nouveau nom de la société est constitué des lettres
      (par exemple, Ecma) et le mot n'est plus alors considéré comme une
      abréviation.</p>
      </div>
    </dd>
[…]
</dl>

And compare to what is generated with this proposal (once you remove some parsoid metadata cluter):

<dl>
    <dt>Difinenda termo</dt>
    <dd>
        <ol>
            <li>Unua difino.
                <dl>
                    <dd><i>Alinomita <b>alia termo</b>, <b>tiu samvaloranto</b>, <b>sinonimo</b></i></dd>
                    <dd>Angla: <b>Term to define</b>, <b>other term</b>, <b>that equivalent</b>, <b>synonym</b></dd>
                </dl>
            </li>
            <li>Dua difino
                <dl>
                    <dd><i>Alinomita <b>alia dua termo</b>, <b>tiu dua samvaloranto</b>, <b>dua sinonimo</b></i></dd>
                    <dd>Angla: <b>Term to define<i>, </i></b><meta typeof="mw:Placeholder">
                    <i>other second term'<meta typeof="mw:Placeholder"></i>, <b>that second equivalent</b>, <b>second synonym</b></dd>
                </dl>
            </li>
        </ol>
    </dd>
</dl>

Ok, having a deeper look at it, I think this should be better from a html validity and structure meaning point of view:

;Difinenda termo
:#Unua difino.
:#;Alinomita: alia termo, tiu samvaloranto, sinonimo
:#;Angla: $english_term, $english_synonym1, $english_synonym2, $english_synonym3
:#Dua difino.
:#;Alinomita: alia termo, tiu samvaloranto, sinonimo
:#;Angla: $english_term, $english_synonym1, $english_synonym2, $english_synonym3

Which give the following end result (but css can be used to change that)

Difinenda termo

1. Unua difino.

   Alinomita

   alia termo, tiu samvaloranto, sinonimo

   Angla

   $english_term, $english_synonym1, $english_synonym2, $english_synonym3

2. Dua difino.

   Alinomita

   alia termo, tiu samvaloranto, sinonimo

   Angla

   $english_term, $english_synonym1, $english_synonym2, $english_synonym3

Here is the corresponding valid html generated (metadata clutter appart):

<dl>
	<dt>Difinenda termo</dt>
	<dd>
		<ol>
			<li>Unua difino.
				<dl>
					<dt>Alinomita</dt>
					<dd> alia termo, tiu samvaloranto, sinonimo</dd>
					<dt>Angla</dt>
					<dd> $english_term, $english_synonym1, $english_synonym2, $english_synonym3</dd>
				</dl>
			</li>
			<li>Dua difino.
				<dl>
					<dt>Alinomita</dt>
					<dd> alia termo, tiu samvaloranto, sinonimo</dd>
					<dt>Angla</dt>
					<dd> $english_term, $english_synonym1, $english_synonym2, $english_synonym3</dd>
				</dl>
			</li>
		</ol>
	</dd>
</dl>

Any feedback on this? :P

In enwiki's draft-status Manual of Style page, there's a section advising against semi-colon/colon, with many technical details and test-cases: w:en:Wikipedia:Manual of Style/Glossaries#Avoid semicolon-and-colon wikimarkup for glossaries - I'm not sure how thorough or accurate it is.

Instead, we've been slowly (over the last 7 years or so) been adopting this template system: w:en:Wikipedia:Manual of Style/Glossaries#Template-structured. There's a list of benefits given below the example (for example, built-in HTML anchors for each term, and valid/semantic/well-formed output). An in-use example is w:en:Glossary of architecture.

However, I don't know if that's a good long-term plan, or if it's suitable for adoption in other (particularly multilingual/translated) wikis.

Could someone review the preparations for translation and enable it if everything is ok?

Than can be the next step for translations listed here? https://phabricator.wikimedia.org/T151766

Possibly but now, before it's marked for translation, I would be interested with having feedback on the suggestion I made to use :# and :#: as a best practice for multiple definitions on a single term and their relative notes.

Have you seen any documentation listing this as a best practice?

This is an approach inspired by what is done on wikitionnaries. Although, curiously we don't use ; for each entry, but begin with a #.

what is done on Wiktionaries may not be the best practice... ;)

The W3C itself use tables to represent glossary : https://www.w3.org/2015/spatial/wiki/Glossary_of_terms

But not here : https://www.w3.org/2003/glossary/subglossary/All/

See also https://www.w3.org/Translations/WCAG20-fr/#glossary for an example of translated glossary publish by W3C. Not mention of English term counterparts, but some definition list have rather deep and complex structure which might be inspiring.

All glossaries I've found from the W3C are using definition lists.

The goal of our glossaries is to have simple definitions that can be easily translated. I prefer not to go deep in creating rules, and try to keep everything simple.