accessibility: add Slovenian translations#90
Conversation
* Linked `accessibility.typ` * Indented the list
* Added phrases * Added prefixes * Added units * Added power shorthands * Added incomplete starter plurality
* Implemented the `pluralize` to add the possible pluralities * See GitHub comment
|
Here's how I'm going about the pluralities so far: Feminine:
Masculine:
About masculineHere, tesla is indeed masculine, so tesla-tesli-teslov is also correct, but I think less common. Code-wise, treating tesla as feminine would be more compact, but no other units which would follow the same rule there. Another example where more choices are possible is dan which can be dneva-dnevi-dnevov. The masculine's ❯❯ are special rules for:
These special rules can be hardcoded for the More:
About moreThese ❯❯ are all simple feminine and could follow the same rule as the feminine non-compounds. I used the A few more questions:
So a TDLR of this commit could be that I:
|
* Added floats into consideration
Since this is always the genitive singular, it's possible to implement into what I have added so far:
|
* Fixed link in TOC * Changed link from German to English Wikipedia
* Added overlooked space to joined words * Tested the code, see the GitHub comment
|
In the code tests, via a snippet, I fixed these issues:
Used test snippetIn multiplication of two same units, I noticed odd behaviour, but I also think such notation should be replaced by the user to use powers, so #set text(lang: "sl")
#set page(columns: 2)
#let unit-keys = units.sl.keys()
#let counts = (-5.5, -5, -4, -3, -2, -1.0, -1, 0, 1, 1.0, 2, 3, 4, 5, 5.5)
#let guad(unit, count) = repr(count) + " " + generate-unit-alt-description(
..parse-unit(unit).values(), value: count
) + "\n"
#context for unit in unit-keys {
for count in counts {
// Lone
guad(unit, count)
// Prefix
guad("µ" + unit, count) // Must not be `sym.mu`
// Multiplication can even be this way?
guad(unit + " " + unit, count)
// Division
guad(unit + "/1", count)
guad("1/" + unit, count)
guad(unit + "/" + unit, count)
}
divider()
}
// Still untested:
// * `#generate-num-alt-description()`
// * `#parse-numeral()`
About this, I have now also made a new revelation. The units in the denominator should always use the accusative singular. I overlooked this because masculine stays the same, apart from the special unit tesla. However, feminine is prone to change. See this for example: So the current quoted rule More observations:
|
|
Hi @hpcfzl , Thank you for adding support for Slovenian! I am surprised about the richness and degree of complexity that this language offers regarding plurals! Let me go through your remarks and questions one by one.
The inheritance is only used for the units and prefixes actually, to reduce the file size since many of those are common across languages.
Such case also exist for other languages that are already supported, however, I think it is out of scope to address this. After all, this feature is used to inform visually impaired people about the documents content and not to be grammatically flawless and idiomatic.
Regarding those, as I understand, there is no difficulty with the gender with the versions that you currently implemented (i.e. na kvadrat instead of kvadratna)? Also in English you can do both square meters or meters squared and I went for the latter.
👍 Thanks!
Don't worry to much about this. I format with typstyle usually.
A few tests for notable cases like irregular plurals etc would be great. There is already an accessibility test file where the usage is already demonstrated.
Sure, that's up to the language. |
Exactly! The other ones are so rare that I don't think it's worth to add them.
Russian is actually not supported yet. I just found the list of prefixes somewhere but then realized this was beyond my expertise... I hope someone will add Russian eventually.
Good question. I could mention you on further PRs regarding Slovenian.
Great! |
|
Regarding tests: since your language is so much more complex with plural, it would be good to have some comprehensive tests for this. |
First of all, be careful, the value is always a float, never an integer. If it is necessary to distinguish between 5 and 5.0, we could make a change to Line 373 in ae87e42 and convert to int if the fraction is
This is unfortunate because it makes everything much more complex. But passing a boolean flag for denominator would work.
Good catch I will update this myself. Actually the idea with being responsive to the region is good, I will consider this.
Yes, this seems like a more specific convention that is out of scope for this project. There are similar examples with German and Finnish. |
|
Thank you also for the corrections to the package read-me! Next time,I would prefer them to be in a separate PR but for now it's OK, just leave it in. Also, it seems that at least part of the commits and messages were AI assisted (correct me if I'm wrong). Since the translation and pluralization of the units is quite complex, this seems okay but I would appreciate an overview of which parts this applies to. It is important for me to know what was human-reviewed, because of course I could also ask AI myself but I couldn't judge the quality of the output for most languages. |
I can already disprove this. I suspected you might think that, and I can't blame you, however I can assure you it's 0%-AI. I really did take all that time. In fact, I wouldn't trust AI for this as it's still not as reliable as the grammar sites intended for this. The same is true for code. The confusion about the invalid syntax would be due to not testing anything until my last commit there. Thanks for also taking the time to answer on your side, I'm going to treat your replies with the same amount of diligence. |
Thanks for clarifying! In this case I'm very sorry to even have assumed this and I want to thank you the more for your effort and for taking the time for your outstandingly detailed discussion of your thought and implementation process. This is very much appreciated! |
Beside what you already answered, I see now that the
Indeed, ¤ na kvadrat I believe is a pronoun and can be used the same everywhere. Whereas kvadrat* ¤ is an adjective based on the noun it's behind and is therefore different between genders.
I added one in a later reply, but that covers all possibilities.
I also asked this to find where |
I thought that the unit of are is common enough at least in Europe, otherwise I agree.
I wouldn't mind that. |
I did list the special plural rules in my initial reply, see About masculine. So I suppose we could have a test for each -5.5, -5, -4, -3, -2, -1.0, -1, 0, 1, 1.0, 2, 3, 4, 5, 5.5 for each:
|
Yes, that needs to be distinguished, but unless I missed something, my test revealed that it's already correct without this change. See for example 1 mol versus 1.0 mola.
Should I add this, or did you intend to? We use an unrelated
All right, this might be something to mention at the end of |
* Applied review suggestions * Corrected the comment about combined words being all-feminine
* Implemented accusative singular for the unit in a denominator
Please excuse my patience. So I decided to add this
Now I'm tempted to add the power shorthands kvadratna sekunda, as opposed to sekunda na kvadrat. But also not really because to determine kvadratna, the additional Please also review the Footnotes
|
* Removed unnecessary comment
|
Without the kvadratna sekunda change, here's the latest snippet to be used for the tests. I observe no error: Latest test snippet#let compare-sl = context {
let nums = (-5.5, -5, -3, -2, -1.0, -1, 0, 1, 1.0, 2, 3, 5, 5.5, "1/")
// Slovenian units, not all but the first which are unique
// The entries are `unit: (0, 1, 1.0, 2, 3, 5, 5.5, denominator's)`
// A `3` and `4` are always the same, and made inseparable in the code, so only `3` is tested for
// Since the negatives are supposed to be a complete mirror of the positives, the first half of the array is taken from the second
// Rules which only apply at higher counts are tested for lower as well anyway
let units-sl = (
// Feminine, regular
cd: ("kandel", "kandela", "kandele", "kandeli", "kandele", "kandel", "kandele", "kandelo"),
// Masculine, regular
A: ("amperov", "amper", "ampera", "ampera", "amperi", "amperov", "ampera", "amper"),
// Masculine, special hardcoded
d: ("dni", "dan", "dneva", "dneva", "dnevi", "dni", "dneva", "dan"),
H: ("henrijev", "henri", "henrija", "henrija", "henriji", "henrijev", "henrija", "henri"),
lm: ("lumnov", "lumen", "lumna", "lumna", "lumni", "lumnov", "lumna", "lumen"),
T: ("tesel", "tesla", "tesle", "tesli", "tesle", "tesel", "tesle", "teslo"),
// Masculine, special rule for `*ber/*ter`
L: ("litrov", "liter", "litra", "litra", "litri", "litrov", "litra", "liter"),
// Masculine, special rule for `*c/*j`
Gy: ("grejev", "grej", "greja", "greja", "greji", "grejev", "greja", "grej"),
// Combined words
au: ("astronomskih enot", "astronomska enota", "astronomske enote", "astronomski enoti", "astronomske enote", "astronomskih enot", "astronomske enote", "astronomsko enoto"),
sym.degree + "C": ("stopinj Celzija", "stopinja Celzija", "stopinje Celzija", "stopinji Celzija", "stopinje Celzija", "stopinj Celzija", "stopinje Celzija", "stopinjo Celzija"),
)
for (key, words) in units-sl {
words = words.slice(1, -1).rev() + words
if nums.len() != words.len() {
panic("The `nums` and `words` arrays for `" + key + "` need to be of same length")
}
let pairs = nums.zip(words)
let (denom, denom-unit) = pairs.pop()
let guad(u, n) = generate-unit-alt-description(
..parse-unit(u).values(), value: n,
)
// All integer and float numbers
for (count, unit) in pairs {
assert.eq(guad(key, count), unit)
}
// When the unit is in a denominator; a hardcoded count here should be sufficient
assert.eq(guad(denom + key, 99), " na " + denom-unit)
}
}
#compare-slOnly a single unit is tested at once, because more units in the numerator behave the same as English in that they're As I had mentioned previously, the To be complete, this snippet would also need:
Although I don't fully understand what these would test. Otherwise, feel free to add the tests and merge when ready! |
It's sort of a different kind of fallback that is engaged when the language is not supported at all (however, this symbolic notation only works for numbers; for units, everything is much more complex) instead of a default for individual keys.
Ok, then let us stick to the pronoun!
Oh, this is a typo on my part! It should be
That's actually correct, although still less used than hectare, I think. It never even received official status of an non-SI but SI-compliant unit (the hectare on the other hand did, but lost it recently).
👍
That sounds reasonable. It might not be necessary to test all the negative cases as the source code clearly shows that you just take the absolute of the number. One or two cases for negative numbers should suffice. |
I'm confused, the float constructor should always return a float and never. Where can I see your example? I think you didn't push any test files yet.
Sounds good!
We need to distinguish between specifying a unit and how it is displayed. For specifying a unit, no parentheses are supported and you need to repeat the slash. For displaying, zero supports three distinct modes (fractions, inline, powers). However for the alt description, the best unambiguous way is to repeat the
I see that this would give more idiomatic results. But the gain is not worth the complexity I feel, as long as any native speaker would still understand. |
looks good! While you currently only test description generation for units, generate-num-alt-description would be necessary to test description generation for numbers. This is really the easy part, because it only relates to the phrases dictionary. |
This can already be observed in the first test snippet I shared #90 (comment). Simply paste this alongside modules imported into
So for alt, that best way is also the only way from what I understand? This way, the alt for what is interpreted as
Understandable, it's already doable but I agree it's not that necessary when all the added code is considered. |
* Applied review suggestions
* Added near-complete tests
|
I have now commited near-complete tests. What I wondered was:
To further explain this, the tests we have don't use those #context generate-unit-alt-description(..parse-unit("K").values(), value: float(1))This would be 1 kelvina, because it's treated as 1.0 kelvina, but 1 kelvin is correct. So your initial suggestion in #90 (comment) to convert to integer when there's no decimal part would be great. I would have added another test for this as well, or wrap the |
Yes it's the only way. Well x/(y/z) would really be xz/y, not x per yz. I'm not quite sure where you are getting there. Zero only ever allows x/y/z as input which mathematically means x/(yz). Fo the alt description, the word per (or its translation) takes the place of the slash: all units prepended with "per" are in the denominator, all the rest is in numerator. So, for example A·s/(V·m) would be "ampere second per volt per meter". This should be least ambiguous and I don't think parentheses () can be expected to be correctly read with screen readers.
Good point, the description generation uses the current setting for num.decimal-separator which is also used for document output. I figured this would be the easiest way and I would expect users to change this setting according to their language anyway. If we don't trust that, we can also add a key decimal-separator to |
Not any more (there used to be one), it's just important to have a context after setting the language.
Mmh, generate-unit-alt-description(..parse-unit("µA").values()) seems to work correctly.
This is indeed harder to test. All these rather manual tests for the accessibility part are necessary because it is not possible to query the alt description of an equation (to my knowledge). |
I implemented this! |
This makes sense.
You're right, I rephrased the sentence, but forgot to change that as well.
I'm going to change both of
Same here. Still, there's bound to be users who won't.
Yes, I think this would definitely benefit the alt. I don't see how automatic per-language decimal separator would be unwanted. Again, this would be for the alts only. |
Thanks for the float to integer fix regarding this. The behaviour should be correct in actual package use now. I will assume this won't change, and as it's so far not possible to easily test, I added no new test for this. I see you also properly commented on the |
* Changed the tests' decimal separator to a decimal comma * Changed the `mA` test to test for `µA`
I added translations for the decimal separator now!
that's fine I might add tests later 👍 |
|
I'm pretty happy now. If there is nothing more from your side, I am ready to merge this. I'll think about splitting out translations into separate files in the future. |
|
Great, the decimal separator change seems to help the readers for other languages too, at least those quickly found online. I see that you already corrected my overlooked Slovenian Because I don't have the software necessary to screen-read a PDF/UA, and I'm not inclined to perform software setups for them, I only ever confirmed the alt strings, not their actual use as alts in a PDF. But despite this, I'm almost certain that the translation matches to that of PDF readers' interpretation. I have notified https://a11y.si about this, and will provide an update on the verdict. As for HTML, I believe alts should appear as MathML support progresses? Ready to merge! |
I checked that the descriptions actually end up in the PDF and that they are read by the NVDA screen reader. Unfortunately it has no math support for Slovenian but if the descriptions work for English and German, they also should for other languages.
Yes, I hope so. Currently, not even the manual alt descriptions end up in the HTML but I guess this is just a matter of time. Huge thanks for this PR and the great amount of work that you invested in the Slovenian translations in order to work out all the tiny details! 🎉 |
2 participants
Important
Following
language-contribution-guide.md.The language code for this is
sl.Contains dual, cases, and genders.
Possible problems:
needs-pluralfunction might requireneeds-dualas wellI'm unsure about the:
plusandminusare the same as English, I thought they would be inherited as is done for prefixes and units. They're still there for now, but I would remove them and have phrases behave the same as prefixes and units in this regardpower:becquerel,coulomb,gray,henry,hertz,joule,lux,ohm,siemens,sievert,watt, andwebercan be inherited, I chose different words because readers might not pronounce them properly. The single exception isnewtonwhich is otherwise rarelynjuten. Most deliberation was done forhertzandohmNumbers:
Power shorthands:
<unit> to the power of two/three→<unit> squared/cubed→ no more<enota> to the power of two→<enota> na kvadrat→kvadratna <enota><enota> to the power of three→<enota> na kub→kubična <enota><enota> to the power of two→<enota> na kvadrat→kvadratni <enota><enota> to the power of three→<enota> na kub→kubični <enota>Joining prefixes with units:
I would also suggest these regarding
language-contribution-guide.md:accessibility.typcould link to the filetimes,power... list there confused me initiallyMore uncertainties:
.endswith()inpluralize?See these changes in the PR.