Bug 29063 - [DOCS] Manual: Translation issue with repeated strings in system preferences
Summary: [DOCS] Manual: Translation issue with repeated strings in system preferences
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Documentation (show other bugs)
Version: Main
Hardware: All All
: P5 - low major (vote)
Assignee: David Nind
QA Contact: Testopia
Depends on:
Reported: 2021-09-20 20:38 UTC by Katrin Fischer
Modified: 2023-10-29 10:53 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:

Generated HTML of circulation sysprefs chapter (200.44 KB, text/html)
2023-01-20 19:52 UTC, Caroline Cyr La Rose

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2021-09-20 20:38:05 UTC
When translating the preferences in Pootle, the strings of every preference are prefixed with a string, keeping them unique and allowing for a more individual translation. In other words: you can use different translations for Use/don't use, activate/deactivate depending on context and the rest of the sentence.

Now in the manual chapters for the system preferences, this does no longer work. There strings like Use/don't use and activate/deactivate are "collapsed" into one string. So you can only translate it once, which means you can't match the translations you picked for the Koha GUI.

I am not sure how to solve this. Maybe we could think about formatting the preferences in the manual differently so the whole text descriptoin appears as one entry on Pootle?
Comment 1 Katrin Fischer 2021-12-09 12:37:30 UTC
For an example:

Asks: ___ cash registers with the accounting system to track payments.

Default: Don't use
Don't use

So each of those lines get to be a separate string.
Comment 2 David Nind 2021-12-10 06:53:01 UTC
Hi Katrin.

Just to make sure I've understand the problem.

Previously you would get something like 'Don't use' and 'Use' as separate strings to translate.

That way you could translate using the right word, depending on the rest of the sentence for the system preference.

But now you are getting 'Don't use Use' as one string to translate.

Comment 3 Katrin Fischer 2021-12-10 08:56:57 UTC
Actually it's the other way around: 

The problem is that they are separate strings. A lot of the system preferences use "use",  "don't use", "activate", deactivate" as options in the pull downs. 

But when translating you don't always translate them the same way, especially for system preferences where you might need to move things around to make the sentence sound nice and work grammatically.

But because I only get 1 tanslation for "don't use" per file I can't make it work and match what we have in the GUI.

What I would much prefer is it being one string, something like:

Asks: [Use|Don't use] cash registers with the accounting system to track payments. (Default: Don't use)

But this is only one solution to the issue, which is why I wanted to discuss.
Comment 4 Katrin Fischer 2021-12-10 08:58:42 UTC
Maybe if you see it on pootle it explains a bit better (you might have to be logged in):

Comment 5 Caroline Cyr La Rose 2022-12-09 16:19:43 UTC
current options 

1) write the system preference descriptions as "[Use|Don't use] blah blah" 

(this works well with two options, but maybe not with more?)

2) somehow add context to the strings like we do in Koha 

(we need someone to develop this for us?)

3) somehow change how the strings are extracted so that each syspref is extracted individually like in Koha

(we need someone to develop this for us?)
Comment 6 Caroline Cyr La Rose 2023-01-20 19:52:44 UTC
Created attachment 145555 [details]
Generated HTML of circulation sysprefs chapter

Hi all! I tried using method 1 ([Allow | Don't allow] blah blah) to see what could be the hurdles...

See the attached HTML. I only changed the prefs in the "Holds policy" section. I put the default value in bold.

I think it works really well for prefs with two options (Allow / Don't allow).

I also like that it cuts a bit of the text since we don't have to have a Values and Default subsections.

I don't think it will be possible to change them in batch since each is different (some have Allow as default, some have Don't allow as default, some have many choices or no choices).

I had particular trouble with the ones with "nothing" as default and the ones with a multiselect rather than a drop down where you can only choose one (see decreaseLoanHighHolds et al. it has all the problems lol!)

See also OPACHoldsIfAvailableAtPickupExceptions and StaticHoldsQueueWeight et al, which are special too.

Let me know what you think!
Comment 7 Caroline Cyr La Rose 2023-01-20 19:55:41 UTC
The file is also here

Ctrl + F and "Holds policy" to jump to the modified section
Comment 8 Caroline Cyr La Rose 2023-02-14 22:29:17 UTC
I realized the html I attached didn't have the CSS, so it was legible, but not pretty...

Here are some screenshots of what I tried

Simple allow/don't allow preferences, those work pretty well imo https://snipboard.io/jOqF7W.jpg

Several sysprefs in the same block, with "nothing" as default, and a multiselect option https://snipboard.io/FytHOM.jpg

Syspref with "empty" as default https://snipboard.io/1Hh6GM.jpg

Syspref with number value (0 as default) https://snipboard.io/C3yEqe.jpg

Another with several sysprefs in the same sentence, 0 as default value https://snipboard.io/2ZxHrt.jpg

Let me know!
Comment 9 Caroline Cyr La Rose 2023-05-16 15:02:38 UTC
Any opinions on the first option? (see my last comment) Or should we wait for a developer to help us with either option 2 or 3?
Comment 10 Aude Charillon 2023-06-06 16:43:48 UTC
If we aren't able to get some dev opinions on your options 2 and 3 in the next few months, Caroline, I'd say let's go for option 1!

But I'm also hopeful we can ask some questions to friendly devs, at least to get an idea of what would be feasible :-)
Comment 11 Marie-Luce Laflamme 2023-06-07 15:03:09 UTC
Great work Caroline. The option 1 looks nice and tidy, and it's probably the easiest way to fix the issue from the documentation side.

I'll be curious to hear more about option 2 and 3.
Comment 12 Caroline Cyr La Rose 2023-07-12 14:21:06 UTC
Docs team is not so keen on option 1 because it's not very readable.

Option 2, to add context, we don't know how to add it in RST.

Option 3, we'd have to explore how the strings are extracted for translations. In Koha, they delimit strings with <span>. 

I'll explore how to add span in RST. I'd need to know how to run the translation script locally to try stuff on my computer...
Comment 13 Katrin Fischer 2023-10-29 10:53:40 UTC
Adding Jonathan, maybe with his recent work on the manual/translations he knows about a possible solution.