-
-
Notifications
You must be signed in to change notification settings - Fork 116
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
Numbers in Titles make Translation fail #657
Comments
The code block below demonstrates that adding a close parenthesis prevents Sphinx from handling the text as a RST list. A number and a full stop/period followed by a close parenthesis is a common manner for enumerating lists.
results in
Question: Is there a way to test the translations before changing all of the documents? |
Here is another option I just found: escape the full stop/period and we should be able to use the existing format without Sphinx handling them as lists. I suggest this approach.
results in 1. This |
Isn't this just a bug in the tool that extracts the translation sources? https://github.com/SpongePowered/SpongeDocs/blame/stable/source/plugin/manager.rst 1. Dependency Injection
----------------------- seems to work and is translateable. https://github.com/SpongePowered/SpongeDocs/blame/stable/source/contributing/howtogit.rst 1. Forking a Repo
~~~~~~~~~~~~~~~~~ fails (at least for ZH-CN). Both generates a |
If my regex |
I used
However, I did noticed several other Titles that aren't numbered, but aren't translating either. They all had the |
I have spent many hours trying to determine the flow of the SpongeDocs build process to see if I could debug build errors. In the process, I have found two missing links on the Docs homepage:
Using the links in the bottom left-hand corner of the pages, I checked all of the build logs. I have a table at https://pastebin.com/raw/B5NvP61e. The table shows which languages appear to be working and which ones have errors in their build logs. The general rule seems to be that languages without build errors are working, while those with build errors are not. Exceptions are Indonesian, Norwegian, and Netherlands. I used Plugin Manager to check, and I looked to see if "1. Dependency Injection" was in English or not.
Perhaps ST-DDT's comment about the tool needs to be explored before changes are made to the docs themselves. I can't find the tool, don't understand the process, or am missing something. So, I can't check the tool. However, I don't mind making the changes once they are identified and if they are needed in the docs themselves. |
It's possible @Minecrell has some idea where this step it is happening. It's still probably simpler for us to reformat the errant headers than to try tinkering with the Crowdin processing. Also not that languages that fall below 5% translated may drop off the list of built translations, iirc. |
Currently, the homepage is not re-built automatically, so new languages only appear when a new build is triggered manually. I just did that so they show up now. I think I debugged this issue back then and it looked like a bug in Sphinx's translation code. Not the extraction or Crowdin, but rather a bug when the translations are applied during the build. It incorrectly detects the text as enumeration and doesn't apply it properly. @Grauldon Thanks for testing this :) I think there is a pattern in your table but it's not related to build errors: The difference for Indonesian and Chinese is that they changed/dropped the number in the translated docs. That way it's not detected as enumeration and translated properly. Conclusion: The source text (English) is not a problem, it only causes problems within the translated text. Some example links:
|
We have encountered a problem with the way some of the translated Titles in pages are being handled by Sphinx. Any title that starts with a number and a full stop (eg
1. Example
) is treated as a RST list, and the translation isn't applied when the docs are built. The effect is highly visible on many of the published SpongeDocs translations which are near-complete, as the plain English text stands out starkly.The simplest fix we can apply is to change the titles to remove or obscure the number. This is as easy as enclosing it in brackets, i.e.
(1) Example
or by giving the title an overline (eg.--------
the same as the title underline. Either way, a number of pages will need to be amended to sort this problem out.Pages affected (so far):
We could use help identifying all the pages that need amendment, so we can roll it all into one big PR if possible. Thanks to the ever-vigilant 3TUSK for first identifying the issue.
Suggestions are welcome on the preferred fix, or how alternative fixes might be achieved.
The text was updated successfully, but these errors were encountered: