Hi Yuri After your last validation of https://userbase.kde.org/Konsole, I tried to translate in FR the new elements starting at '===Per Konsole tab Bash history ===' but I cannot save. I know I have met the same problem on Mediawiki () but generally submitting twice the EN modified page is sussisant. Here it doest not work. Cannot save nothing. See Maniphest T221119 : dummy update. Help
Yes. It is a known problem of the current version of the Translate extension. Please wait until the database will be updated (it seems we can do it only manually now). There is nothing I can do now. It is Carl's pet.
Meanwhile, you can translate something else. Sorry for this trouble.
Sorry for the trouble. :(
For now there is a script that will do this automatically, but will need to be restarted after each server restart and I created a sysadmin request to make it works after each restart.
I am afraid I have made something of a mess out of your translation of Kdenlive/Manual/Effects And Transitions. All your translated text should be in place but the page displays nothing. I suggest we wait a couple of days to see if this is just fuzzybot playing up. I still have your original text so nothing is lost.
No need to worry. I will revise the translation by myself. Thanks anyway.
Everything is back to normal - your existing translations are back (I didn't touch your recent edits, of course). Silly mistake on my part - I simply forgot to close a brace matching comment.
I started a few days ago an update to the wikis and you can try it at wikisandbox.kde.org. More details are available at https://phabricator.kde.org/T2442. Could you take a look and provide feedback?
Just a note: translations are impossible after the update. Any change cannot be saved wit an error message:
This namespace is reserved for content page translations. The page you are trying to edit does not seem to correspond any page marked for translation.
Thanks in advance for fixing this issue.
…за всю вашу українську документацію. Приходжу я, випадкова людина, читати про Kdenlive, а тут уже (майже) все є. Дякую
Hi Yuri, I ve open this subjet on Jucato's page. Do you have objections ?
do you agree that each FAQ translation of TechBase was being deleted ?
The KDE TechBase page Translations:Development/FAQs/General FAQ/55/fr has been deleted on 16 May 2019 by FuzzyBot, see https://techbase.kde.org/Translations:Development/FAQs/General_FAQ/55/fr.
.... and so on
Long story short: Yes.
KDE e. V. (or rather its Board of Directors) has decided to hire a professional documentation writer to improve our technical documentation. Now we should see what Jucato will do to reach his goal. That's all I can say.
I read in phabricator, that there is a System Settings reorganization planed for Plasma 5.16, so I think that we should wait for 5.16 to be released, before we continue working on the system settings wiki pages (and relevant translation).
I just saw that this wiki has more than 1000 unused images: https://userbase.kde.org/index.php?title=Special:UnusedFiles&limit=5000 That should we do about this? Delete them, or just ignore them?
I wanted to use https://userbase.kde.org/Special:ListFiles to track the remaining screenshots to update, but it's difficult to find old screenshots that are used somewhere.
I think it is safe to delete icons and screenshots for English locale. Localized screenshots with some low probability level can be reused. Do you need some help to do this?
I noticed you marked some of the pages I edited for translation. I'm new to this, but I remember reading new content was automatically marked. Is there something I can do to help you out, perhaps making it myself after editing and adding content, so that you don't have to?
Yes, the breaking into translation units and providing them to the translators is automatic. But somebody has to trigger the process for every translatable page. Moreover, there are things that should be taken into account when doing so (fine granularity of the messages, bracket balance, using consistent numbering of the units). It also needs some additional wiki permissions.
Do you really want to mark the pages for translation? ;)
Hey, I am one of the Krita manual writers.
We are moving our manual to docs.krita.org, which is a mediawiki on kde servers. The benefit of this for us is that we have a bit more flexibility. We will of course be using the excellent translate extension.
Now, one of our translators is a bit confused about the relationship between Krita and KDE, being that Krita is part of KDE, and has put up the majority of our translation pages onto the 'ready for translation' todo, even though we told him not to.
I am not sure what is best now. We will not be updating the pages outside of 'our new docs are at docs.kde.org' on top of each page. And I wouldn't want to give you too much work, but at the same time, I also don't want to confuse you in regards to huge amount of pages that appear and dissapear suddenly from the 'ready for translation' todo.
The topic where this is discussed is here: https://forum.kde.org/viewtopic.php?f=137&t=130557&p=349474 and I am online at #krita during european daylight.
What do you suggest?
I started to translate the page http://userbase.kde.org/Konversation/ru , please check correctness.
Here translate in .po file, idk, how to upload. http://anonymousdelivers.us/90982
Imported. Can you try to import by yourself (Special pages -> Import translations)?
probably next Wednesday (July, 17th) an Ukrainian television crew (www.inter.ua) will visit my OpenPGP course / Cryptoparty (in Berlin, Germany). For obvious reasons there is currently a hype here in Germany about crypto and privacy tools in general and about Cryptoparties in particular. Thus several German television crews will be there, too. Of course, I do not know what exactly they are going to send but if you have finished some of my texts until then then they may mention them (maybe link them from their web page). If you give me your email address (send it to [email protected]) then I can offer them to contact you.
I'm working through the pages available in the Kdenlive Manual, and trying to comply with the page and section markup that helps docbook. I've come across this problem where the Index page shows "Kdenlive on other Desktops and Operating Systems" and it is currently linked to Kdenlive/Manual/KdenliveOnOtherPlatforms. Clearly if a change is needed, now is the time to do it, but I'm not too happy about very long page names. What would be your recommendation in a case like this?
In this case there will be enough to add the anchor
<span id="Kdenlive on other Desktops and Operating Systems">
The general concern is that links should refer to Kdenlive/Manual/KdenliveOnOtherPlatforms#Kdenlive on other Desktops and Operating Systems
This method can be used to avoid renaming Amarok pages.
I know Claus has been talking to you about various such concerns, and that he is building it into Draft:The KDE Documentation Primer. I'm picking up bits as I go along, and when your conversations are finished we should have the ability to generate DocBooks without too much effort - the aim is to have them at the point where they compile every time without needing extra work. Please carry on working with Claus on this, and meanwhile, make any changes you need. I'll learn the needs as quickly as I can
With today's update of the Translate extension, we have two new options in the "I want to" combibox -
Review all translated messages in... and Accept translations in.
These should be useful when you are checking on the work of new and relatively unknown translators. They are only available to translation Team Leaders, at least for now.
Regarding the latest edit of Amarok/Manual/AmarokWindow/PlaylistPane:
Could you please explain what the problem with the recent changes to the Amarok pags was. It is a problematic page, and we need to do something about the placing of images. Anne and I have been trying to make things look decent with little success. The latest attempt using a table is the only thing that has even come close to solving anything.
I agree, of course, that docbook conversion has top priority. Does that mean that we can't use tables for this kind of thing? Perhaps we simply need to force all images to be centered between sections? (That would make this page look very odd.) Any ideas would be much appreciated.
Sorry for not explaining this earlier.
The script is trying to build bijection between two markups. To be clear, the problems with your last edits are as follows
- Script assumes that each raw of the table begins with "| ". Adding <translation> tag gives the XML output "|
Message" That moves Message outside the table in the converted docbook
- KDE docbook commands subset does not have command to scale columns (although generic docbook does). This breaks the current parser (it thinks that "| width="75%" |" is the cell content).
- <br /><br /> is not parsed at all (<para></para><para></para> just triggers the warning).
Surely these problems can be fixed by improving the script. Any help will be appreciated. Instructions can be found here.
P.S. Docbook syntax does not allow using images in captions to images. Please avoid using images templates in the captions. Thanks.
Thanks, this is helpful.
How does KDE docbook handle tables? Is it possible to give some hint of what the column width should be? Could we make, say, 4 colums and then merge 3 of the (an ugly kludge, off course, but if it works...). Or should we avoid tables all together?
Q: Is it possible to give some hint of what the column width should be? A: No, it will be chosen automatically to fit the width. Images will not be scaled down (will be shown as is (100%)).
Q: Could we make, say, 4 colums and then merge 3 of the (an ugly kludge, off course, but if it works...)? A: You could, but the script in its current form does not parse this. Just for the reference the code in docbook for
|Jumping around in code|
|Ctrl+Alt+O||Quick open file: enter part of a filename and select among all the files in the current session's projects' directory trees that match the string; the file will then be opened|
<informaltable> <tgroup cols="2"> <colspec colname="c1"/> <colspec colname="c2"/> <thead> <row> <entry namest="c1" nameend="c2">Jumping around in code</entry> </row> </thead> <tbody> <row> <entry><keycombo>&Ctrl;&Alt;<keycap>O</keycap></keycombo></entry> <entry>Quick open file: enter part of a filename and select among all the files in the current session's projects' directory trees that match the string; the file will then be opened</entry> </row> </tbody> </tgroup> </informaltable>
The problem is in smart parsing for the number of columns to be merged. I have to do it manually for KDevelop manual conversion.
Q: Or should we avoid tables all together? A: No. Generic tables are parsed well. Screenshot
The table width doesn't seem to be as big an issue as I thought. At least when the uploaded images have a sensible size, tables seem to adjust to them nicely.
I tried one more time to make a table to solve the problem, but in a test page User:Claus_chr/Test. Would this work? (apart from the <br /> problem - I havent found out what to do about that yet.)
Update: As a matter of fact I don't need the br tags at all - I just misread the wikimedia docs.
PS. Anne and I was wondering about your comment about images in captions. As far as we know there never was an image in any caption. What are we missing here?
Q: Would this work? A: No. See 1. Can you keep the pipe ("| ") in one unit with the rest of the cell? If you do, then modified script can give something like this.
P.S. I should concentrate on my report now. Can we discuss the rest later? Thanks for your answer.
I wasn't aware of that page at all until yesterday, when I was checking for subpages not translatable. I imagine that it was originally copied from TechBase, and probably by me. Pity I didn't realise that there was no value whatsoever, as I spent a lot of time preparing it :-) Anyway, it is now moved to the Archive namespace and removed from the Translate system. Thanks for the heads-up.
The translations of the ToolBox page are seriously out of date, and I don't think we can get them back in sync with the English page - it was at one time removed from the translation system and then reinstated much later, so now it thinks, that the existing translations are OK even though they are not.
Anne and I agreed that it is best simply to delete the existing translations. We'll wait a bit though, to give you time to rescue your work. Some of it can be reused.
From the page history it seems that your translation is quite recent, but still as far as I can see a translation of a fairly old version. Maybe the old translation units has been kept even after the English page was removed from translation?
It seems that is possible to "repair" this. See User_talk:Caig#The_ToolBox_page_1211. I'll wait a bit longer, if you want to try it out.
This is not the only affected page (I cannot find the others now, but I am sure). Well, I I will repair translation little by little then.