The following page was translated by @avma , there are some code examples and snippets along the page, the code parts should be completely LTR otherwise it’s very complicated to understand it.
The headers are also automatically LTR (although aligned to the right), which garbles the sentences and make it harder to understand.
Does the following MediaWiki support page abot sectional overrides for directionality help?
<div dir="rtl"></div> and also inserting the RLO character (RIGHT-TO-LEFT OVERRIDE, U+202E) at the start of the code and the PDF character (POP DIRECTIONAL FORMATTING, U+202C) at the end.
Well sort of, It better be automatically for all code boxes but I guess it can work for now, I’ll send an account request.
Even with decades of experience writing HTML and with various CMS tools, becoming productive as a WikiContributor difficult.
It required simultaneously learning:
- the MediaWiki markdown language
- the Gramps Wiki typographical conventions
- the article organization (or disorganization) and the discovering the holes
- and I was new to the subject matter too: Gramps
The new WikiContributor onboarding was (and is) non-existant. ( “Welcome to Gramps! We hope you will contribute much and well. You will probably want to read the help pages.”) The referenced help pages are from MediaWiki, not the Gramps wiki. So that’s drinking from a firehose.
We put together a “Onboarding Survey” that’s a little more specific to our wiki.
As you get started, please note any problems you have becoming productive in improving translations. Feel welcome to keep those notes on the discussion page of the “Translating the Gramps User manual” wiki article.
And do you believe migrating to a newer version will solve some of these caveats?
Are there plugins supporting these operations or everything should be done manually?
The updating problems have roadblocked trying out tools that might help. There are MediaWiki addons for translators.
Is there somewhere I can download the whole dump and try to upgrade it manually?
@garygriffin has written a script to compile the main chapters of the wiki as a singe (offline) html file. It strips off the WikiMedia extra stuff as well.
Could you and @avma proofread (or spot check) the Hebrew PDF manual generated from that HTML file? 4 files were generated to test his automation. the basefile (English), a latin alphabet translation (Dutch), a non-latin ltr alphabet (Russian), a rtl layout (Hebrew).
Hi and thank you for this wonderful work!
The code part is right aligned and I need to help @avma with more screenshots and some typos I found while skimming through the pages but overall it’s pretty comprehensible (except for the untranslated parts).
This is a screenshot showing the right aligned code block:
I also want to express my thanks to @GaryGriffin for this wonderful work.
He put in a lot of effort and made many revisions cycles. And he had to fix (or compensate for) a lot of inconsistencies in the wiki too.
It is nice having an offline copy in HTML format too. It raises a future possibility of having the Help button in Gramps route to the offline manual when you have no connection.
This is where maintaining the English anchors in the translated wikipages is going to become important… and probably that’s not known by translators.
Each heading style is an “anchor” for web navigation. So Gramps might link to
https://gramps-project.org/wiki/index.php/Gramps_5.1_Wiki_Manual_-_Gramplets#What_is_a_Gramplet (which is
== What is a Gramplet? == in the english wiki markdown) but the header is
= מה זה גרמפלט? = in the translated page.
I don’t know if we’ve figured out headings as anchors in translated wikipages
You can create a manual anchor in this case:
==<span id="What is a Gramplet?"></span>מה זה גרמפלט?==
See the Internal links section of the mediawiki manual. Look at the “Setting an anchor for incoming links” example.
The part that is confusing is the complication of the hashtag target when the URL has a “translation redirection” parameter too.
So where do you put the hashtag (
#מה_זה_גרמפלט ) for a
help_url will be Gramplets#What_is_a_Gramplet.3F".
The url will be constructed as “https://gramps-project.org/wiki/index.php/Gramps_5.1_Wiki_Manual_-Gramplets/he#What_is_a_Gramplet.3F”, if the user’s language is set to “he”.
This could then re-direct to a page with a Hebrew title, but in this case it doesn’t.
All that is needed is an invisible English anchor to be added to the Hebrew section heading.
I am wondering 2 things:
- if the index.php parser can handle both a hashtag target AND a language redirection parameter. (If so, how? Does the hastag go before or after the language parameter?)
- if the process wouldn’t be greatly simplified by specifically avoiding having a translated anchor and hashtag target? Or by doing a double ID?
The combination of ltr and rtl components in a URL is complicating the matter. Maybe troubleshooting 1 part at a time by using a ltr language would be reasonable.
Take the French Gramp glossary term “lieu” (Place) under L.
You will notice that the lieu term has no
span anchor… the only anchor is the alphabetization index (a MediaWiki header) for L. Meanwhile, the English eqivalent is under ‘P’ and the Place term has a manually added anchor:
The index.php for:
If the ‘lieu’ term actually had an english equivalent in a double ID (
<span id="place"><span id="lieu">lieu</span></span>), it would simplfy things a little, translaters could spend less time harmonizing Help URLs, internal wiki links and evolving translations. Plus support is usually in english and tweaking a URL to insert a
https://gramps-project.org/wiki/index.php/Gramps_Glossary#place is a lot easier than guessing the arbitrarily chosen term in your language.
But how could this anchor be used with the
index.php/Gramps_Glossary/fr parameterized URL?
I’ve just been testing this.
We have a function called
display_help(webpage, section) which displays help pages from our wiki. The base url points our wiki, so you have to add the prefix for the user manual, if required.
will display the “What is a Gramplet?” section in the “Gramplets” page in our user manual.
This also works with the Hebrew translation of the manual. I had to add an anchor to the wiki page and add Hebrew to the list of user manual translations.
It is important to separate the webpage and section, so that an url pointing to a translated page can be constructed. This was not the case with the gramplet bars, so I’ll fix them.
I notice that in many parts of Gramps the section name is translated. This has lead to confusion in the past because these strings have been translated even when no translated version of the manual page exists. If no translated manual exists we want the English help page displayed. The alternative is to add invisible English anchors to the translated web pages.
I’ll investigate if we have any manual page translations problems in Weblate.
I am hoping that the use of English anchors might eliminate the need for Weblate for the help_url
If you can always call with the language code (since MediaWiki fallsback to the english page if the translation page doesn’t exist), then you can take Weblate harmonization (with the github pushes of translations that wait for releases, and constant programmer labor) out of the equation. Instead of shared responsibility, the entire burden will be solely on the wikicontributors. They wouldn’t have to coordinate with anyone and their changes would be immediate.
This would eliminate a huge amount of work and glossary entries for the Weblate translators.
There are 68 manual section strings in Weblate. They all have the context “manual” and have the following explanation:
“Used as part of a link to a wiki manual page. This string should only be translated if a corresponding translated manual page exists. Underscores should be retained.”
I also set a condition that the translated text must not contain spaces.
Despite this, many strings have been translated into languages that don’t have a translated manual.
The “Attribute_Editor_dialog” has been translated into French such that it doesn’t match the section heading in the French manual causing the link to break.
If you find issues with the PDF User Manual in Hebrew, please check to see if the issue is also in the Wiki page. If it is, then it needs fixed in the Wiki page to be correct in the PDF. The PDF should look like an extraction from the Wiki page with Table of Contents, language tables at top and bottom, and bottom nav removed.
I can regenerate the PDF if there are fixes to the Wiki page.
The process for generating the PDF is described at Gramps 5.1 Manual Creation - Gramps . I included all of the scripts needed for en, nl, ru, and he languages.
This definitely caused more work for the PDF compilation process. Right now, my process will work either way, so it is independent of whether there is ‘encouragement’ to make english-only anchors.