In http://sourceforge.net/projects/freeplane/files/do%20not%20use%20me/ I have put a freeplane version 1.6.0_08 . It contains all fixes of 1.5.15_01 and it allows UI designers and translators to easily change text strings from the most parts of Freeplane user interface including menu actions, property panel and preference items.
To use the new feature press CONTROL + SHIFT + F10 when your mouse pointer is above the text you want to change. If the text can be changed a dialog to change the current text is displayed. In the same dialog you can also set a tool tip text.
After you close Freeplane your new text strings are saved in UserResources_XX.properties file in your user config directory, and if you send me this files using bug reports I can import them directly into the freeplane sources. This version still users the same configuration directory as Freeplane 1.5 .
The hot key to start the translation editor dialog van be changed by executing action Tools -> Set text change hot key.
I think this way is much easier than using weblate ofr translations. However we still need weblate for strings which are not covered by this tool. And I am not sure whether this feature should be added to standard freeplane distribution.
Regards,
Dimitry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am looking into how to translate Freeplane at the moment see thread [3b20093b].
The new translation feature solves one problem I have with Weblate: in Weblate you only see a context string and you have to guess where in Freeplane this string is used. It also makes choosing unique &-mnemonics very easy. Personally I do not care about these mnemonics, but others might.
At the same time, if somebody sends you an UserResources_XX.properties file, what do you know about the quality of this persons translation? He or she could mess up the work of other translators for the same language. This problem is solved by Weblate, because here translators can collaborate and check each others translations.
And is it really so much easier? The translators and you have to do several manual steps. Are these steps not automated in Weblate? How many of these files do you expect to receive in one month?
So why not combine the two? In stead of sending it to you, the translator could upload the UserResources_XX.properties file to Weblate. Of course we need to test this. Does the UserResources_XX.properties file contain all translation items or only the the changed items. If it contains all items I would not know if Weblate is smart enough to only make new entries for the changed or new items.
I would prefer a different feature: a feature that gives you a copy of property/context string. This allows you to quickly search in Weblate for the right entry. Then you can first check the English source string, the remarks, history and preferred translations from the glossary. In my opinion this information can increase the quality of the translation tremendously and you will miss this information in the new feature. I would prefer this option because I find quality more important than ease of use.
It would be nice if such a feature would also work for add-ons. Though add-on translators do not use Weblate, it still helps them to find the property string at a certain location.
What do you mean by "translations" in "I think this way is much easier than using weblate ofr translations."? The offline translations with Popeye? I have removed this information from the Translation How-To page, because I believe it combines all the above disavantages that Weblate and the new translations feature have.
I cannot think of any disadvantages of shipping it with the Freeplane standard distribution. If we are not sure, why not shipping it as a Translators add-on?
I have another question. I have seen one case of a property string that is used in 2 places: plugins/TimeManagement.xml_WindowTitle. If you do not know this, you could choose a translation which does not fit both situations. How many strings are used in multiple places? If there are only a few cases, could you provide me with a list of property strings where this applies to? I can than enter this information in the remarks for these property strings. If there are a lot, could a translation feature also provide this information?
based on your suggesions I added a button for direct navigation to the relevant text in weblate to the translation dialog. So now sending me the file is not a single way to communicate your text and translation changes. It is already available in Version 1.6.0_09 .
At the same time I want to explain that I never review translations made on weblate. I need to trust translations as language experts. I have never had any troubles with translations coming from weblate.So if somebody wants to add a lot of translation strings, may be even a new language, I think sending me a file is easier than using weblate web site for big amount of changes.
Regards,
Dimitry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is a great addition! Does it also navigate to the translation of the right language based on the Freeplane language setting?
Of course I did not expect you to review translations on Weblate, What I mean is that on Weblate translators to the same language can review each others work. If a person submits a file directly to you, co-translators cannot review this work.
I have more collaboration concerns. I can remember that in 2010 I did a lot of Freeplane translation work in Popeye and that Jodi later repeated a lot of the same work because he started with an older language file that did not include my translations. Similar thing can happen if you allow people to submit translations outside weblate.
Allowing people to only use Weblate gives a lot of control:
Translators always work based upon the latest translation (no double work)
Peer review possible
Logging of who has done what
Consistent translation because of glossary
Possible to give guidelines by remarks
When allowing people to also submit files directly to you, I can think of the following risks and disadvantages:
Double work because people work in parallel without knowing it from each other
Double work because of not working with the most recent version
Overwriting a new translation with an old translation because of not working with the most recent version (assuming that the new feature includes unchanged translations in the file)
Overwriting an other person's translation without knowing it.
In Weblate history you cannot see who has done the translation sent to you and added by you
Translation lacks consistency because of not working with a glossary
So maybe these risks and disadvantages can be mitigated as follows:
Only use the feature for mass or new translations
Only use the feature when you can do the translation in a short period, e.g. less than a week
Mention on the forum that you are going to do this offline translation in existing or new language translation thread
In case of existing translation, download the most recent translation from Weblate and install it locally
After finishing translation, upload it to Weblate
Translator or co-translators should review the imported entries for consistency and unwanted overwriting of
I do not know the exact import functionality of Weblate, but I hope that it does not make new entries for unchanged translations and that it marks new and changed translations for review.
What do you think? Any better ideas? Maybe functionality to automatically download and upload the local translation from/to Weblate?
Cheers,
Henk
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, it considers the language and the key and actually shows the url as a button tool tip.
Weblate is always in sync with out github repository, currently with branch 1.5.x .
And you also can download trynslation property file directly from weblate, put it into folder <fp-user-config>/1.5.x/resources/translations/ (create it if needed) and so let your freeplane version use it so that you can continue your work based on this state. Your UserResources_xx.properties has higher priority, so you should delete it if you want to have exactly the last weblate state.
I performed a test (with the PortableApps version under Windows 10) and I am really impressed!
I have updated an existing translation and added a new translation. Then I uploaded the file to Weblate. That went perfect. I think this should be the only way to merge the local file with git. Is there any situation were you really need to merge it yourself in git, e.g. when there are new translation keys in a new release?
Uploading the file to Weblate also gives the translator useful options like adding it as a translation that needs review or whether or not to overwrite existing translations. I have no clue what I can expect from the option 'Merge file header' so I disabled it.
I discovered that you can also use the translation editor to translate the translation editor ;-)
I did not find any bugs in the translation editor. I have some possible improvements though. You might want to look at the should haves before merging it into 1.5.x.
Apart from the translation editor I observed that the user directory is 1.5.x instead of 1.6.x. Is this on purpose or a mistake?
Must haves
None
Should haves
I think the translation editor should be a Easter egg function for translators, only communicated on the Translation How-To page. Taking into account the discussion on Freeplanes confusing user interface, the addition of "Set text change hot key Ctrl+Shift+F10" to the tool menu increases the confusing for the average user. You could remove this menu item and prevent Ctrl+Shift+F10 from being assigned to other functions. Instead of a Easter egg function you could also make it into an translation editor add-on.
The tool tip strings not available at Weblate also do not have an English source strint (at least as far as I can see). So there is nothing to translate and I think they should be hidden in order to prevent confusing. Since I do not know if it can do any harm, I have not tried to upload these 'translations' to Weblate. I guess the upload will just fail. If someone can think of a situation where you need such an additional tooltip for a certain translation they could let it know in this thread.
Could haves
Offline adding of a comment and/or review flag to a specific translation, e.g. if the translator is not sure about the translation and wants it to be reviewed by a co-translator in Weblate. According to the Weblate upload interface it is possible to merge translation comments. There is also a dropdown menu for translation strings needing review, hence my assumption you can add a review flag. I am also not sure whether the format of UserResources_XX.properties allows it.
Function to download or refresh <fpuserdir>/1.5.x/resources/translations/Resources_<lang>.properties from Weblate
Function to upload UserResources_XX.properties. This function should allow one to specify the same options as in the Web interface, with exception of Merge file header which can be disabled (unless someone tell us that this option can be useful for us).
Would haves
If Weblate is already opened in web browser, it would be convenient if the same web browser tab would be reused when pressing the translation editor button to open the relevant text in Weblate. My estimate is that this is not possible or at least too complicated to develop.
Apart from the translation editor I observed that the user directory is 1.5.x instead of 1.6.x.
Is this on purpose or a mistake?
I have not changed the configuration it yet, and this version should become 1.5 again.
Should haves
I think the translation editor should be a Easter egg function for translators, only
communicated on the Translation How-To page. Taking into account the discussion on Freeplanes
confusing user interface, the addition of "Set text change hot key Ctrl+Shift+F10" to the tool
menu increases the confusing for the average user. You could remove this menu item and prevent
Ctrl+Shift+F10 from being assigned to other functions. Instead of a Easter egg function you could
also make it into an translation editor add-on.
I do not think the action should be removed from menu because it would be confusing too.
Maybe we need a new option to enable both the action and the shortcut.
The tool tip strings not available at Weblate
also do not have an English source strint (at least as far as I can see). So there is nothing to
translate and I think they should be hidden in order to prevent confusing. Since I do not know if
it can do any harm, I have not tried to upload these 'translations' to Weblate. I guess the
upload will just fail. If someone can think of a situation where you need such an additional
tooltip for a certain translation they could let it know in this thread.
This tool is considered also for improving user interface, not only for improving translations. Therefore it allows to change texts and to add tool tips.
I can disable it but I am not sure what is better.
Could you please try what happens if you upload a file with a tooltip? I think it is likely to be ignored. But may be if you upload the english version the new keys are added. Could you please try it?
Could haves
Offline adding of a comment and/or review flag to a specific translation, e.g. if the
translator is not sure about the translation and wants it to be reviewed by a co-translator in
Weblate. According to the Weblate upload interface it is possible to merge translation comments.
There is also a dropdown menu for translation strings needing review, hence my assumption you can
add a review flag. I am also not sure whether the format of UserResources_XX.properties allows
it.
Do you still need the weblate button if you can upload your translation files directly to weblate (I didn't know it before)
Function to download or refresh
<fpuserdir>/1.5.x/resources/translations/Resources_<lang>.properties from Weblate
Function to
upload UserResources_XX.properties. This function should allow one to specify the same options as
in the Web interface, with exception of Merge file header which can be disabled (unless someone
tell us that this option can be useful for us).
I do not know much about the upload functionality and I think there shouldn't be too close connection between weblate and freeplane.
Regards,
Dimitry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the translation editor should be a Easter egg function for translators, only communicated on the Translation How-To page. Taking into account the discussion on Freeplanes confusing user interface, the addition of "Set text change hot key Ctrl+Shift+F10" to the tool menu increases the confusing for the average user. You could remove this menu item and prevent Ctrl+Shift+F10 from being assigned to other functions. Instead of a Easter egg function you could also make it into an translation editor add-on.
I do not think the action should be removed from menu because it would be confusing too.
Maybe we need a new option to enable both the action and the shortcut.
Adding another option to Preferences? I thought that the maximum had been reached ;-) I think turning it into an add-on is the best option. Could Volker not do that? If that is not an option for you, I would just change the name to a name that makes clear it is specifically for Freeplane translators, e.g. "Change hot key Freeplane translators function"
The tool tip strings not available at Weblate also do not have an English source strint (at least as far as I can see). So there is nothing to translate and I think they should be hidden in order to prevent confusing. Since I do not know if it can do any harm, I have not tried to upload these 'translations' to Weblate. I guess the upload will just fail. If someone can think of a situation where you need such an additional tooltip for a certain translation they could let it know in this thread.
This tool is considered also for improving user interface, not only for improving translations. Therefore it allows to change texts and to add tool tips. I can disable it but I am not sure what is better.
Could you please try what happens if you upload a file with a tooltip? I think it is likely to be ignored. But may be if you upload the english version the new keys are added. Could you please try it?
I have tried. For both translation and English the uploaded tooltip string is ignored. The bad thing is that Weblate does not give feedback that these strings are ignored. This means for new tooltips the UI designer or translator needs to send the English version to you by bug report. Is it true that after merging the new translation key is available for all languages? After that the normal translation process can follow.
You are combining 2 roles, 2 functionalities and 2 processes in one tool. This might be difficult to explain to the user. At first I thought you should make it into 2 separate functions. You could also add the following functionality.
If there is no English source string the text entry field is disabled for all languages except for English.
In case of English there is a tool tip/message that the UserResources_en.properties tooltip entry should be forwarded as bug report, referring to the Translation How-To page - New tool tip section.
In case of othere languages there is a tool tip/message that an English source string should be entered before translation, referring to the Translation How-To page - New tool tip section.
I have put a concept of the new tool tip user processes. I think this is reasonable straight forward and fool proof. What do you think?
On the same page it says you cannot change the English source strings in Weblate. In fact you can, I made a small correction and you can find it back in git. The processes are almost identical as for translation. I think we can give the community the responsibility to maintain and improve these source strings, don't you think so? Can I add a section for that? Should the developers have a special review role in this process?
Do you still need the weblate button if you can upload your translation files directly to weblate (I didn't know it before)
Yes please, it is very useful! It depends on the activities and requirements of the translators.
Use offline translations:
for large amounts of new entries: for translation to a new language or for a language that still needs a lot of new entries
if speed is more important than quality
if you can do a lot in a short time
if you can make sure that you are the only one working on your language or if you have
Use online translation with Weblate and button
for changing existing entries (you can see history, source string)
if quality is more important than speed (in Weblate there is more information and supporting tools)
if you can do a bit of translation from time to time
if you want to collaborate without investing a lot of time in getting organised
Another should have improvement of the translation editor is that you make the English source string visible. Especially when changing existing translation, but also for new entries: in the beginning the source string is there but after some typing it dissapears.
Cheers,
Henk
Last edit: Henk van den Akker 2016-08-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think turning it into an add-on is the best option. Could Volker not do that?
I could. The add-on could provide its own preference options to be used by the translation feature.
But regarding the tooltips I think that that could be worked out manually by developers or tools that search for new translation keys. Not too bad if you ask me - it just had to happen once in a while before a release.
Volker
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I implemented some of the changes you suggested in version 1.6.0_10 . Now to enable the feature user should install the attached add-on. In the translation dialog there are tool tips showing the original english text. Also the weblate button is disabled for strings not available yet.
Now I need your help. The attached addon does not have any description and also no valid home page yet. Could you please extend it and prepare it to be released?
If I get your go and the modified addon version (you can edit the attached map and send it back to me) I shall merge all changes in Freeeplane 1.5.x and the functionality becomes available to everyone.
I just typed a whole piece into this thread and it just disappeared after posting. Grrrhhaa! Could this happen because in the meantime you had posted an other message?
Anyway, I do not know if Volker is being ironic, but I do think this is an elegant solution. The add-on just enables the translation functionality, so I assume you can just release a version 1 and there is no need to ever update it, since the translation editor updates will come in the new releases of Freeplane itself. Right?
I will add a description to the add-on. I will make the Translation How-To its home page and I will try to attach it to the same page, so it can be downloaded from there. Good idea? Since it will not be updated there is no need to put a version.properties I guess. I have already documented the translation editor quite a lot on this page, except for the fact that is now an "add-on". My holidays are over so you might need a bit of patience.
Dit you read the new tool tips processes I proposed? I think for a clear process it is essential that you disable translation of new tool tips as I tried to suggest. I tested Freeplane 1.6.0_10 portable version under Windows 7 and found that I could still enter a translation for a new tool tip, i.e. a tool tip without an English source string and translation key in Weblate/git. The translation will end up in the UserResources_XX.properties file, but as we have concluded before, uploading it to Weblate does not add anything and the user might not even aware of it because there is not feedback. Or do you have another process in mind? I assumed you do not want to receive translations of keys that do not have an English source text yet, right?
Instead of disabling offline translation you have disabled the Weblate button for new tool tips. That was not really necessary, because in this situation the translator receives a feedback from Weblate that the translation key cannot be found and the reason is explained in the Translation How-To.
By the way, you seem to have quite some Chinese and Japanese alpha testers. Do they have a special interest in translation?
Cheers,
Henk
Last edit: Henk van den Akker 2016-08-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just typed a whole piece into this thread and it just disappeared
after posting. Grrrhhaa! Could this happen because in the meantime you
had posted an other message?
Anyway, I do not know if Volker is being ironic, but I do think this is
an elegant solution. The add-on just enables the translation
functionality, so I assume you can just release a version 1 and there
is no need to ever update it, since the translation editor updates will
come in the new releases of Freeplane itself. Right?
I will add a description to the add-on. I will make the Translation
How-To its home page and I will try to attach it to the same page, so
it can be downloaded from there. Good idea? Since it will not be
updated there is no need to put a version.properties I guess. I have
already documented the translation editor quite a lot on this page,
except for the fact that is now an "add-on". My holidays are over so
you might need a bit of patience.
Dit you read the new tool
tips
processes I proposed? I think for a clear process it is essential that
you disable translation of new tool tips as I tried to suggest. I
tested Freeplane 1.6.0_10 portable version under Windows 7 and found
that I could still enter a translation for a new tool tip, i.e. a tool
tip without an English source string and translation key in
Weblate/git. The translation will end up in the
UserResources_XX.properties file, but as we have concluded before,
uploading it to Weblate does not add anything and the user might not
even aware of it because there is not feedback. Or do you have another
process in mind? I assumed you do not want to receive translations of
keys that do not have an English source text yet, right?
Instead of disabling offline translation you have disabled the Weblate
button for new tool tips. That was not really necessary, because in
this situation the translator receives a feedback from Weblate that the
translation key cannot be found and the reason is explained in the
Translation How-To.
By the way, you seem to have quite some Chinese and Japanese alpha
testers. Do they have a special interest in translation?
If you think it should belong to the standard freeplane distribution and it is good enough, I shall include it in one of the stable 1.5.x versions.
Another point: some tool tip strings are not available at weblate. You can still add tool tips using this tool but there is no corresponding weblate key because no tool tip text was defined before.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Almost 2 years ago I corrected 3 Dutch translation entries and they are all undone. This undoing is not visible in the Weblate history, see example screenshot below. In the git history of Resources_nl.properties I can find back that my changes were committed on 14-10-2014. On 2-12-2015 somebody replaced the resource files undoing my changes. I have 2 questions about this:
How can this be prevented?
If a mistake like this happens, could it be reflected in the Weblate history?
I can see that an 2-12-15 something could go wrong and it is not a common pattern. The reason for this changes was that we had to change some keys in the translation files. I am sorry. It is not unlikely that some valuable translations have been lost on this day, and may be you can find them in the git history again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
User translation support is included in 1.5.16_01 . Now when somebody documents and releases the add-on I sent you every user can install it and help with ui changes and translations.
Cheers,
Dimitry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
great, thank you! It is exactly what I wanted you to do. This addon is not a part of freeplane distribution, but people who want to do translations can download and install it.
In http://sourceforge.net/projects/freeplane/files/do%20not%20use%20me/ I have put a freeplane version 1.6.0_08 . It contains all fixes of 1.5.15_01 and it allows UI designers and translators to easily change text strings from the most parts of Freeplane user interface including menu actions, property panel and preference items.
To use the new feature press CONTROL + SHIFT + F10 when your mouse pointer is above the text you want to change. If the text can be changed a dialog to change the current text is displayed. In the same dialog you can also set a tool tip text.
After you close Freeplane your new text strings are saved in UserResources_XX.properties file in your user config directory, and if you send me this files using bug reports I can import them directly into the freeplane sources. This version still users the same configuration directory as Freeplane 1.5 .
The hot key to start the translation editor dialog van be changed by executing action Tools -> Set text change hot key.
I think this way is much easier than using weblate ofr translations. However we still need weblate for strings which are not covered by this tool. And I am not sure whether this feature should be added to standard freeplane distribution.
Regards,
Dimitry
Hi Dimitry,
I am looking into how to translate Freeplane at the moment see thread [3b20093b].
The new translation feature solves one problem I have with Weblate: in Weblate you only see a context string and you have to guess where in Freeplane this string is used. It also makes choosing unique &-mnemonics very easy. Personally I do not care about these mnemonics, but others might.
At the same time, if somebody sends you an UserResources_XX.properties file, what do you know about the quality of this persons translation? He or she could mess up the work of other translators for the same language. This problem is solved by Weblate, because here translators can collaborate and check each others translations.
And is it really so much easier? The translators and you have to do several manual steps. Are these steps not automated in Weblate? How many of these files do you expect to receive in one month?
So why not combine the two? In stead of sending it to you, the translator could upload the UserResources_XX.properties file to Weblate. Of course we need to test this. Does the UserResources_XX.properties file contain all translation items or only the the changed items. If it contains all items I would not know if Weblate is smart enough to only make new entries for the changed or new items.
I would prefer a different feature: a feature that gives you a copy of property/context string. This allows you to quickly search in Weblate for the right entry. Then you can first check the English source string, the remarks, history and preferred translations from the glossary. In my opinion this information can increase the quality of the translation tremendously and you will miss this information in the new feature. I would prefer this option because I find quality more important than ease of use.
It would be nice if such a feature would also work for add-ons. Though add-on translators do not use Weblate, it still helps them to find the property string at a certain location.
What do you mean by "translations" in "I think this way is much easier than using weblate ofr translations."? The offline translations with Popeye? I have removed this information from the Translation How-To page, because I believe it combines all the above disavantages that Weblate and the new translations feature have.
I cannot think of any disadvantages of shipping it with the Freeplane standard distribution. If we are not sure, why not shipping it as a Translators add-on?
I have another question. I have seen one case of a property string that is used in 2 places: plugins/TimeManagement.xml_WindowTitle. If you do not know this, you could choose a translation which does not fit both situations. How many strings are used in multiple places? If there are only a few cases, could you provide me with a list of property strings where this applies to? I can than enter this information in the remarks for these property strings. If there are a lot, could a translation feature also provide this information?
Best regards,
Henk
Related
Discontinued Forums replaced by GitHub: 3b20093b
Hi Henk,
based on your suggesions I added a button for direct navigation to the relevant text in weblate to the translation dialog. So now sending me the file is not a single way to communicate your text and translation changes. It is already available in Version 1.6.0_09 .
At the same time I want to explain that I never review translations made on weblate. I need to trust translations as language experts. I have never had any troubles with translations coming from weblate.So if somebody wants to add a lot of translation strings, may be even a new language, I think sending me a file is easier than using weblate web site for big amount of changes.
Regards,
Dimitry
Hi Dimitry,
That is a great addition! Does it also navigate to the translation of the right language based on the Freeplane language setting?
Of course I did not expect you to review translations on Weblate, What I mean is that on Weblate translators to the same language can review each others work. If a person submits a file directly to you, co-translators cannot review this work.
I have more collaboration concerns. I can remember that in 2010 I did a lot of Freeplane translation work in Popeye and that Jodi later repeated a lot of the same work because he started with an older language file that did not include my translations. Similar thing can happen if you allow people to submit translations outside weblate.
Allowing people to only use Weblate gives a lot of control:
When allowing people to also submit files directly to you, I can think of the following risks and disadvantages:
So maybe these risks and disadvantages can be mitigated as follows:
I do not know the exact import functionality of Weblate, but I hope that it does not make new entries for unchanged translations and that it marks new and changed translations for review.
What do you think? Any better ideas? Maybe functionality to automatically download and upload the local translation from/to Weblate?
Cheers,
Henk
Yes, it considers the language and the key and actually shows the url as a button tool tip.
Weblate is always in sync with out github repository, currently with branch 1.5.x .
And you also can download trynslation property file directly from weblate, put it into folder <fp-user-config>/1.5.x/resources/translations/ (create it if needed) and so let your freeplane version use it so that you can continue your work based on this state. Your UserResources_xx.properties has higher priority, so you should delete it if you want to have exactly the last weblate state.
In freeplane wiki there is http://www.freeplane.org/wiki/index.php/Translation_How-To , if you like you could update it. Maybe we should wait until I merge this feature into the 1.5.x release branch.
Do you think it is good enough to do it right now?
Hi Dimitry,
I performed a test (with the PortableApps version under Windows 10) and I am really impressed!
I have updated an existing translation and added a new translation. Then I uploaded the file to Weblate. That went perfect. I think this should be the only way to merge the local file with git. Is there any situation were you really need to merge it yourself in git, e.g. when there are new translation keys in a new release?
Uploading the file to Weblate also gives the translator useful options like adding it as a translation that needs review or whether or not to overwrite existing translations. I have no clue what I can expect from the option 'Merge file header' so I disabled it.
I discovered that you can also use the translation editor to translate the translation editor ;-)
I did not find any bugs in the translation editor. I have some possible improvements though. You might want to look at the should haves before merging it into 1.5.x.
Apart from the translation editor I observed that the user directory is 1.5.x instead of 1.6.x. Is this on purpose or a mistake?
Must haves
None
Should haves
Could haves
Would haves
Cheers,
Henk
Last edit: Henk van den Akker 2016-08-15
I have not changed the configuration it yet, and this version should become 1.5 again.
I do not think the action should be removed from menu because it would be confusing too.
Maybe we need a new option to enable both the action and the shortcut.
This tool is considered also for improving user interface, not only for improving translations. Therefore it allows to change texts and to add tool tips.
I can disable it but I am not sure what is better.
Could you please try what happens if you upload a file with a tooltip? I think it is likely to be ignored. But may be if you upload the english version the new keys are added. Could you please try it?
Do you still need the weblate button if you can upload your translation files directly to weblate (I didn't know it before)
I do not know much about the upload functionality and I think there shouldn't be too close connection between weblate and freeplane.
Regards,
Dimitry
Hi Dimitry,
Adding another option to Preferences? I thought that the maximum had been reached ;-) I think turning it into an add-on is the best option. Could Volker not do that? If that is not an option for you, I would just change the name to a name that makes clear it is specifically for Freeplane translators, e.g. "Change hot key Freeplane translators function"
I have tried. For both translation and English the uploaded tooltip string is ignored. The bad thing is that Weblate does not give feedback that these strings are ignored. This means for new tooltips the UI designer or translator needs to send the English version to you by bug report. Is it true that after merging the new translation key is available for all languages? After that the normal translation process can follow.
You are combining 2 roles, 2 functionalities and 2 processes in one tool. This might be difficult to explain to the user. At first I thought you should make it into 2 separate functions. You could also add the following functionality.
If there is no English source string the text entry field is disabled for all languages except for English.
In case of English there is a tool tip/message that the UserResources_en.properties tooltip entry should be forwarded as bug report, referring to the Translation How-To page - New tool tip section.
In case of othere languages there is a tool tip/message that an English source string should be entered before translation, referring to the Translation How-To page - New tool tip section.
I have put a concept of the new tool tip user processes. I think this is reasonable straight forward and fool proof. What do you think?
On the same page it says you cannot change the English source strings in Weblate. In fact you can, I made a small correction and you can find it back in git. The processes are almost identical as for translation. I think we can give the community the responsibility to maintain and improve these source strings, don't you think so? Can I add a section for that? Should the developers have a special review role in this process?
Yes please, it is very useful! It depends on the activities and requirements of the translators.
Use offline translations:
Use online translation with Weblate and button
Another should have improvement of the translation editor is that you make the English source string visible. Especially when changing existing translation, but also for new entries: in the beginning the source string is there but after some typing it dissapears.
Cheers,
Henk
Last edit: Henk van den Akker 2016-08-23
I could. The add-on could provide its own preference options to be used by the translation feature.
But regarding the tooltips I think that that could be worked out manually by developers or tools that search for new translation keys. Not too bad if you ask me - it just had to happen once in a while before a release.
Volker
Hi Henk,
I implemented some of the changes you suggested in version 1.6.0_10 . Now to enable the feature user should install the attached add-on. In the translation dialog there are tool tips showing the original english text. Also the weblate button is disabled for strings not available yet.
Now I need your help. The attached addon does not have any description and also no valid home page yet. Could you please extend it and prepare it to be released?
If I get your go and the modified addon version (you can edit the attached map and send it back to me) I shall merge all changes in Freeeplane 1.5.x and the functionality becomes available to everyone.
https://sourceforge.net/p/freeplane/discussion/758437/thread/3ef06c77/aad3/c365/a78b/bdc7/18dc/a7f4/de4f/attachment/User%20Translation%20Support.addon.mm
Best regards,
Dimitry
Last edit: Dimitry Polivaev 2016-08-21
https://sourceforge.net/p/freeplane/discussion/758437/thread/3ef06c77/aad3/c365/a78b/bdc7/18dc/a7f4/de4f/attachment/User%20Translation%20Support.addon.mm
Hi Dimitry,
that's a very elegant solution! It would every competition for effectiveness :-).
Volker
Hi Dimitry,
I just typed a whole piece into this thread and it just disappeared after posting. Grrrhhaa! Could this happen because in the meantime you had posted an other message?
Anyway, I do not know if Volker is being ironic, but I do think this is an elegant solution. The add-on just enables the translation functionality, so I assume you can just release a version 1 and there is no need to ever update it, since the translation editor updates will come in the new releases of Freeplane itself. Right?
I will add a description to the add-on. I will make the Translation How-To its home page and I will try to attach it to the same page, so it can be downloaded from there. Good idea? Since it will not be updated there is no need to put a version.properties I guess. I have already documented the translation editor quite a lot on this page, except for the fact that is now an "add-on". My holidays are over so you might need a bit of patience.
Dit you read the new tool tips processes I proposed? I think for a clear process it is essential that you disable translation of new tool tips as I tried to suggest. I tested Freeplane 1.6.0_10 portable version under Windows 7 and found that I could still enter a translation for a new tool tip, i.e. a tool tip without an English source string and translation key in Weblate/git. The translation will end up in the UserResources_XX.properties file, but as we have concluded before, uploading it to Weblate does not add anything and the user might not even aware of it because there is not feedback. Or do you have another process in mind? I assumed you do not want to receive translations of keys that do not have an English source text yet, right?
Instead of disabling offline translation you have disabled the Weblate button for new tool tips. That was not really necessary, because in this situation the translator receives a feedback from Weblate that the translation key cannot be found and the reason is explained in the Translation How-To.
By the way, you seem to have quite some Chinese and Japanese alpha testers. Do they have a special interest in translation?
Cheers,
Henk
Last edit: Henk van den Akker 2016-08-23
No irony involved - I really like the solution.
Volker
Am 23. August 2016 01:28:13 MESZ, schrieb Henk van den Akker haaihenkie@users.sf.net:
Dimitry,
With regard to the Translation How-To, I am already in the process of updating it and will add the information with regard to the translation editor.
Cheers,
Henk
Now the new version is only available at https://sourceforge.net/projects/freeplane/files/do%20not%20use%20me/ .
If you think it should belong to the standard freeplane distribution and it is good enough, I shall include it in one of the stable 1.5.x versions.
Another point: some tool tip strings are not available at weblate. You can still add tool tips using this tool but there is no corresponding weblate key because no tool tip text was defined before.
Hi Dimitry,
Almost 2 years ago I corrected 3 Dutch translation entries and they are all undone. This undoing is not visible in the Weblate history, see example screenshot below. In the git history of Resources_nl.properties I can find back that my changes were committed on 14-10-2014. On 2-12-2015 somebody replaced the resource files undoing my changes. I have 2 questions about this:
Cheers,
Henk
Last edit: Henk van den Akker 2016-08-15
I can see that an 2-12-15 something could go wrong and it is not a common pattern. The reason for this changes was that we had to change some keys in the translation files. I am sorry. It is not unlikely that some valuable translations have been lost on this day, and may be you can find them in the git history again.
Hi Dimitry,
I will check it for Dutch. I will put a section on the translation how-to page so others can do it for other languages.
Cheers,
Henk
User translation support is included in 1.5.16_01 . Now when somebody documents and releases the add-on I sent you every user can install it and help with ui changes and translations.
Cheers,
Dimitry
Hi Dimitry,
I have completed the information in the add-on, uploaded it to the Freeplane wiki and now you can directly download it from this section: http://freeplane.sourceforge.net/wiki/index.php/Translation_How-To#Freeplane_translation_editor. Or did you want to include it in the release files? I have also attached it to this post.
Cheers,
Henk
Last edit: Henk van den Akker 2016-08-23
Hi Henk,
great, thank you! It is exactly what I wanted you to do. This addon is not a part of freeplane distribution, but people who want to do translations can download and install it.
I have put the addon file to https://sourceforge.net/projects/freeplane/files/addons/user-translation-support/ and changed the link on the wiki page.
Regards,
Dimitry