Giters

vkbo / novelWriter

novelWriter is an open source plain text editor designed for writing novels. It supports a minimal markdown-like syntax for formatting text. It is written with Python 3 (3.9+) and Qt 5 (5.15) for cross-platform support.

Home Page:https://novelwriter.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Translations of novelWriter

vkbo opened this issue · comments

commented

As of January 2022, translations are managed through the crowdin project page.

If you want the repository credit for large translation efforts, you can make a direct pull request. Otherwise, please don't make pull requests for translations. If you have produced a translation file locally, you can upload it yourself directly on the Crowdin page, and your translations will be added automatically.

If you want to contribute a new translation, or have any other relevant questions, please make a post in this issue thread.

Going forward, the process will be as follows:

  • For each pre-release of novelWriter, the Main GUI translation file will be updated and uploaded to the Crowdin tool.
  • At the full release, the translation files, in whatever state they may be, will be downloaded and added to the release.
  • If necessary, files will also be updated for patch releases.

Last updated on 2022-02-12

commented

volunteering for French when ready ...
regards,
Jan

commented

Excellent. I will try to get the translation framework ready soon.

commented

I can translate to Korean and Chinese. Let me know if it ready :)

commented

I can translate to Brazillian Portuguese and maybe help with the i18n development

commented

I can translate to Brazillian Portuguese

Excellent

and maybe help with the i18n development

If you have any experience with this for PyQt5 projects, it would be interesting to have a topic on the discussions page on how to implement it. I have made one branch in the past trying to do this, but abandoned it in the end.

commented

I started a POC this weekend, I intend to open a WIP PR soon.

commented

I had a look at your branch, and it already looks good. Thanks a lot for doing this. We can discuss more in the WIP PR, but two things just from the start:

  • The PR should be based on the current dev branch, as it will go in for release 1.3. There are some GUI changes in the dev branch that will likely affect this PR. Mainly in build.py, but there are also two new GUI files in the current main branch added in 1.1, which were merged after you forked the repo.
  • Please also run flake8 on the code to check the coding style if you haven't already. It's described in the CONTRIBUTING file what is checked and what is ignored. It looks like some of the code lines are too long to comply with PEP8, but I may be mistaken. The flake8 check is run on push to the PR, so it will anyway run the check for you.

Edit: I'll add a note of the post-1.0 branching policy in the CONTRIBUTING file. I intend to keep main on stable code, and do all new development for the next releases on the dev branch. It makes it less risky for users to just clone main and run the code. Only patches will be applied directly to main going forward.

commented

About the linter, I'm just adding the translations as fast as possible, I'll run flake8 before open the PR.
I noticed the large merge you did recently, I'll rebase accordingly too.
Also I'll reorganize the commits in a more logical order.
But thanks for the feedback!!

commented

@longqzh

I added translation support and portuguese translation, it would be nice if you could check what is required to proper chinese internationalization.

commented

Thanks to @bkmeneguello, the internationalisation effort for novelWriter is now in the dev branch, and will work its way into the main branch for release version 1.3. Bruno has provided the Portuguese translation, and I've added one of the Norwegian written forms.

This issue will be used to continue to coordinate the translation effort. I think it's a good idea to not make translations continuously, and instead focus on the full releases, and perhaps also select pre-releases. We will see what works best. Note that support for RTL languages is likely not complete at this point.

A brief guide has been added to the i18n folder describing how to contribute translations: https://github.com/vkbo/novelWriter/tree/dev/i18n

Since text is inserted into the exported project, a set of translation files have been added for the three words plus the "number words" used for this. These are just JSON files, and should be easy to translate. These work independently from the main GUI translation files, and I've added a separate dropdown box on the Build Novel Tool for selecting the language for exports.

commented

@jyhelle NW is now ready for French!

commented
commented

Great! Just keep in mind that the manual is a work in progress and still changes quite often as I get feedback from users who ask for clarifications. I am also continuously adding to it.

But the translations of the manual don't need to follow that closely. The most important thing is that they are helpful to the users.

commented

I have never looked into what's required for translations of readthedocs documentation, but I found a guide here: https://docs.readthedocs.io/en/stable/guides/manage-translations.html

commented
commented

I figured out a way to get translations on the Qt widgets (mostly dialog buttons) for languages that don't have a localisation file shipped with Qt. I'm adding a dummy_qtbase.py file in the i18n folder with QT_TRANSLATE_NOOP entries for the buttons and labels we need.

These translation entries will show up in the .ts files under the context names starting with Q for the Qt widgets. If the language you're translating already has entries for the Qt widgets in the global qtbase_xx.ts/.qm files, leave these blank. For other languages, fill them in. This applies to Norwegian and Portuguese at least. French and German will not need it.

I'll add this to the i18n readme as well.

commented

The translation to French is done, I shall play with the app for one or two days to check and certainly polish a word here or there before uploading the .ts and .json files, but from a quick overview it seems OK.

commented

Great! I'm making a couple of improvements to how the Preferences and Project Settings dialogs are laid out to make them more flexible size-wise for translated texts that may be different in length than English. I can merge that PR now. It's ready.

Mainly, it allows the help text labels in these dialogs to be line wrapped. It is a bit tricky since they behave quite differently when word wrap is on, but I think I've solved it.

commented
commented

I cannot immediately reproduce this, but could you make a new issue, explain how to make this happen, and copy/paste the content of the error message? When an error occurs, nW tries to still save your project, and will try a controlled shutdown afterwards. Since nW uses the Qt library, which is written in C++, a crash on the C++ side will break elements of nW, so the only safe way is to shut down and start again.

commented

As for the part about line wrapping, it is of course best if the translated text is roughly the same length as the English text as that is what the GUI was originally designed for. Although on dialog boxes and in tooltips, and other locations which already have line wrapping or plenty of room, it doesn't matter.

The approach to reword or try to convey the meaning by using different words or phrases is a good approach. I did that several places with the Norwegian translation. Norwegian sometimes requires more space than English, but I know enough French to know this is trickier with that particular language.

commented
commented

@jyhelle, I see you don't have a fork of novelWriter for submitting a pull request for the French translation. I assume you've just been editing local files. Since your GitHub account is empty, I'm not sure how familiar you are with git, and if you're not, just send me an email and I'll give you a howto. I have one I use for work when people ask. I think you have my email address.

commented

I just published a beta release of the internationalisation version:
https://github.com/vkbo/novelWriter/releases/tag/v1.3b1

Thanks for all the contributions. I will make a few more tests and tweaks before I make a release candidate in a couple of weeks. The language files for French and Norwegian are fine. There are 11 missing translations in the Portuguese. There may be more changes before the next release, so I will make a post here ahead of time so everyone has a chance to catch up. Between the release candidate and final release I only fix bugs, so there will likely not be changes after that.

Edit: Note that the 1.3 code has been moved out of the dev branch and now lives in the testing branch.

commented

Note that I've updated the About dialog to list contributions differently, and include translations. Let me know if you want to change the information listed there.

commented

I will try to update the PT translation today

commented

Great! There's no rush though. I will not make the release candidate before at least April 11. I want to work with the beta release for a while first to see if it works fine.

commented

Today I've released 1.2.3 with a minor bugfix, the release candidate of 1.3 with all the internationalisation code and translation files, and then merged the whole 1.3 branch into the main branch.

I expect to release the 1.3 final release with all of your contributions in a week or two once I've tested it. I'm not sure how many use the pre-releases, but it would be great if those of you who've provided translations either test out the code in the current main branch or download the 1.3 RC 1 release. There are no missing translations, but in case there are mistakes you want to correct, or changes to make, it would be nice to have them in the 1.3 final release.

Thanks a lot for all your contribution, and especially @bkmeneguello who did most of the work implementing the translation code.

If anyone else here want to add new translations, please start from the dev branch and make pull requests there. The dev branch is the starting point for the next release, 1.4.

commented

@longqzh

I added translation support and portuguese translation, it would be nice if you could check what is required to proper chinese internationalization.

Hi, @bkmeneguello
Thanks very much for adding internationalization!

Hi, @vkbo
I added Chinese support and send PR to dev, please check and merge it :)

#817

commented

Thanks a lot! There is a minor change I need you to make. I've added a comment on it in the PR. Otherwise it looks great :)

commented

I've just released 1.4 release candidate 1, which means 1.4 will be up in a couple of weeks. The new Simplified Chinese translation is already up to date, and I'll update the Norwegian. The Portuguese and French will also need a minor update. There are 24 new entries to be translated.

The 1.4 RC 1 release has been merged into the main branch, so the translations should be made from that branch as well.

commented

I just downloaded the file, but QtLinguist finds no pending translations ...

commented

You have to run the setup.py qtlupdate command first to update the file. I try to avoid commiting updated ts files all the time as they clutter up the repository with large diffs.

Edit: If you don't have the tools installed, I can email you the updated file if you'd like. Just let me know.

Edit 2: I emailed it anyway, just in case. :)

commented

I have now released 1.5 Release Candidate 1. I've updated the US English and Norwegian translations.

Due to the removal of novel file layouts, and replacing these with different features, there are a number of changes to the GUi that requires new translations. 51 entries as far as I can see. There are a few more missing from Portuguese as this file wasn't updated for 1.4 either.

I plan to make the full 1.5 release around September 19th. If any of you want your translations updated for 1.5, I'd need them before that.

I can email you the file again if you need me to, @jyhelle. It's not a problem.

With the new release, a PDF manual is shipped with novelWriter. This makes it possible to build and ship your French translation of it as well, but the documentation has changed quite a bit since you did the work. I suppose it is a bit much to keep up with.

commented
commented

I will send the file. As for the PDF manual, it is probably better to implement the translation tool that the documentation package is designed to work with. I will look into it.

commented

Hey @vkbo! I've been very busy these days and couldn't keep the translation updated. But today I configured an integration that could make our lives much better: https://crwd.in/novelwriter

I've shared the project on crowdin.com that allows us to have unlimited opensource projects managed. I set it up and everything is working now. There are integrations that you (as the owner of the Github project) can do. I will be happy to transfer the ownership of this project to you and help you to integrate this into the build workflow (but I suppose you will not need it since you are a very capable developer ;) )

To generate the translations you just need to click the "Build & Download" button.

Some tiny changes need to be made to the project: the i18n/nw_en_US.ts must be renamed to i18n/base.ts and uploaded to crowdin in the "content" tab (but I think with Github integration this could be done automatically). Then anyone can add the translations online and follow up the updates. Then, when you download the build artifact, it can be added to the i18n dir and voilá, everything will be there.

Please, let me know WDYT. As soon as you add yourself to the project I can promote you to manager (or look for some way to transfer the ownership).

Best regards!

commented

Hi! Thanks for setting this up. I'll look into making the needed changes. By the way, the base language is en_GB, not en_US, but I can probably generate the file. It's quite late here now, so I'll look at this maybe tomorrow. No need to transfer ownership. I'm happy to co-manage it.

commented

Ok, I've signed up.

I noticed that the tool doesn't accept that there are strings that don't need to be translated. That will be an issue between US and GB English, as almost all of them are the same. It is also why the Norwegian translation is at 98% and not 100%.

commented

Maybe it's something in the configs. I noticed I can't add you as a manager. The "free" version only accepts one. I'll ask the support to migrate the ownership (for your future safety).
I'll check the config.

commented

I see what you said about the translations, but it's a good practice to have all strings translated, even when they are the same. I did it in the Portuguese translation. In Norwegian, you could only click the button "Copy source" to have them overwriten.

commented

If they migrate it, that's ok. I'm just a bit reluctant to have another auxiliary tool to keep track of and maintain. I currently have three that are low maintenance, but it's quite enough. This project is already taking up considerable chunks of my free time. I'm also wondering how to attribute the translators when the work doesn't come as a PR from a GitHub account, or has many authors.

commented

Are the example project documents translatable? It would be nice to be able to load them in the configured language.

It would give the user a full "native" introductory experience.

commented

No, the sample project is mostly intended for testing during code development. But there's a proposal to add template project support (#841) which would be a more natural way to support multiple languages.

commented

Oh. And here I was thinking the sample project was a killer feature. 🙃

So currently in new releases, the new project wizard does not allow users to create a sample project?

commented

Also: there is a non-localisable string "Save" in the Save button under Project Settings dialog > Auto-Replace

Screenshot

commented

Please file bug reports in separate issues. There's no way to properly track issue progress when filed in the middle of a thread, even if on a related topic.

commented

So currently in new releases, the new project wizard does not allow users to create a sample project?

The create sample project feature will be replaced with a template project feature when it is ready. There are several proposals of useful templates that can be added to a standard set of templates shipped with novelWriter, in addition to letting the users make their own.

commented

I'm sorry, and I've now filed #919.

commented

I need to understand the meaning of some strings. Posting these here so that other translators can benefit from the answers:

  • Constant
    • "Objects": As in objectives? As in material/stuff?
    • "Entity": The new project dialog allows you to set an "entity folder". Is it supposed to only hold one entity document? Otherwise I need to use a plural form of the word. (In fact, the Spanish plural form works best for all uses of "Entity" in novelWriter.)
  • NWProject
    • "Backup from {0}": Is "Backup" here a verb or noun?

Edit: Also, are we translators supposed to choose the accelerator key on menu items? I noticed all menu items are bare of accelerators, but that it is possible to assign them (in which case QT Linguist complains about the lack of an accelerator in the original string).

commented

@vkbo Please provide clarification on the above so I can finish the es_419 localisation.

commented

Sorry, missed this one. I'm a bit overworked at the moment.

  • "Objects": As in objectives? As in material/stuff?

It's described in the documentation, but "object" as in "physical object", Like for instance to track which scene a certain object of importance appears in.

  • "Entity": The new project dialog allows you to set an "entity folder". Is it supposed to only hold one entity document? Otherwise I need to use a plural form of the word. (In fact, the Spanish plural form works best for all uses of "Entity" in novelWriter.)

The singular/plural of these constants isn't properly consistent. The folder should really be plural, and each entry in the folder singular. But since the user can edit the folder label, it isn't really an issue.

  • "Backup from {0}": Is "Backup" here a verb or noun?

Noun, short for "the backup created on ...". It's the filename of the backup file.

Edit: Also, are we translators supposed to choose the accelerator key on menu items? I noticed all menu items are bare of accelerators, but that it is possible to assign them (in which case QT Linguist complains about the lack of an accelerator in the original string).

They are only assigned to the top level menu entries, and should be made unique within a single translation.
The entries within each menu doesn't have such keys as most of them have keyboard shortcuts instead.

commented

Hi there, I noticed a minor mistake in the Chinese translation. In the project menu, the 11th option "Move the item up" (or something similar in English) was translated into "向下移动条目“, which means "Move the item down", and you can see it's exactly the same as the 12th option, which is the correct down one. The correct one for the 11th should be "向上移动条目”. It's a minor typo but it would still be nice to have it fixed. Since I haven't dived into the project, I chose to report it here. But if you prefer to me fixing it I would be glad to help.

commented

@Quanzzzz Hi, thanks for your feedback:)

commented

Just to clarify here... Is Crowdin the way forward for translators? I already use it for a couple of other apps I contribute to, so this would tie in nicely.

commented

The Crowdin setup was done by @bkmeneguello a while back, but I don't know the status of it. I cannot extract any translations from it, so I don't know what to do about it. I don't really want to maintain another auxiliary service either, and I was not very happy with the Crowdin user interface when I tried it out.

When we added @tmarplatt's Spanish translation, he improved the documentation, and I made a few improvements to the way new translations are added. You can now do it directly from command line, and the TS file format supports annotations from the latest XML format from Qt. Everything is available with the setup.py script.

Edit: Here are the instructions by the way: https://github.com/vkbo/novelWriter/tree/main/i18n

commented

Hey all! Since I was mentioned, let me contribute a little here.
Well, the initial internationalization setup was also made by myself, with the great finalization made by @vkbo. But after a while I found some drawbacks with this scheme: first, it requires the proper setup of some tools, like QtLinguist, not readily available to other platforms (I'm a W$ user now, but was a Linux at that time). Second, it's subject to versioning and formatting issues, this is very cumbersome sometimes, but I think this should affect @vkbo more than us. Third, we don't have visibility about the translation necessities, so, it requires the translators always to check the project for missing updates.
So, some time ago I set up the Crowdin project to fix these issues, which looks like @vkbo has transferred to a new maintainer. This project aimed to replace all the translation functionality from Qt, but it comes with its own quirks. It should not be used to translate all source files, but only *.ts files. These files must be removed from the Github project and only a default (en_GB.ts) must be kept, with a generic name, like base.ts. Then, when @vkbo wants to release a new version, or during the setup.py invocation, the translated files must be downloaded from crowdin.com and named accordingly. This way no translator must install any tools, we have the visibility and are notified about translation drifts from crowdin. But, to everything work, @vkbo must integrate the crowdin project to the GitHub repository, so it installs a webhook to update the files when commits are published.
If you want to know more about how to integrate Crowdin I can help, just let me know.

I created a new project, for testing, on my fork. A crowdin.yml file is required to restrict the translated files. The translated files can be downloaded through API or direct download.

commented

I've been playing a bit with the configuration now, but I'll have a look again after work.

I don't understand why the current .ts files must be removed? Can't I just set the current folder as an output directory and have Crowdin make pull requests or at least push to a branch?

commented

They could, it's another option, you can update the translated files in your repo whenever you want, this must be done periodically to keep then up to date but allows the project be cloned and already bring the translations.

Another point I remembered, the only drawback about CrowdIn is it requires that untranslated strings (like OK) to be copied to the translated files to show it as 100% translated. I don't see a problem with that since it ensures the author's intention to have this word untranslated, which differs from the "not yet translated" alternative.

commented

@vkbo you would be only required to update the "base.ts" file when something is changed in the project, but it could be a pre-commit hook anyway.

commented

My opinion is that in the end it is up to @vkbo what to use. However, a tool like Crowdin does save translators a lot of time and headaches to add and maintain translations for a project. Though I'm primarily a developers / devops engineer, I use Crowdin to keep translations for two or three projects up-to-date. (as a translator)

commented

I'll give it a try. I know the way to do translations with Qt Linguist is very clunky. Especially when you're not on Linux and have to install the entire Qt SDK.

I've added a nw_base.ts file to the repo, and decided to go with manual uploads. I think the GitHub integration is a bit messy. I'll upload a new base file well ahead of each release, and add a bash or python script to sync down new translations and push them to the repo ahead of releases.

Is there any way to properly keep track of authors for major contributions? I want to credit those who do the initial translations at least, as it's quite a large job.

commented

Well, after the CrowdIn integration there is a "Report" view where you can check the contributors and the languages they contribute. Also, is possible to restrict who can contribute or who can accept the translations for each language, which can be mentioned apart.
image

commented

I've updated the sticky post at the top, But basically what I've done is:

  • I've added a new nw_base.ts file to the repository. Together with project_en_GB.json, I will keep these files manually up to date on the crowdin project page. The current state of the crowdin project page is what was in the repository right now.
  • I will update these files for pre-releases. I will include the contributed translations when I make the final releases. I'm just going to download the results as a zip file. I've added a command to setup.py that will import them to the correct locations. I will commit the downloaded files with the release PR itself, or just before.

I'm not sure if people can add new languages themselves, but if not, I can do that when people post here. Did you want to contribute with Dutch, @mvdkleijn? I'll add it right away.

commented

I noticed one issue. I can only have 60000 words to translate, which is only ~13 languages. That may become a bit of a problem. The prices for Crowdin are quite steep.

commented

Did you check they have an open source request page? Maybe they can grant you an increased quota. Looks like this project fits all their criteria.

commented

I can probably do that, yes. It may also be a good opportunity to prune some of all that GUI text. There are over 4300 words. I'm deleting all the status tip entries in the main menu. They are pretty much all redundant.

commented

I joined the Crowdin project. It's my first time using this tool and I already like the ability to add contextual descriptions to strings.

I'm a little upset that comments got stripped from the source file, but only a little 🙂 They're not too many and I'm moving them to the Crowdin interface, but I must say it's odd that this kind of source metadata gets tied to the translation platform instead of remaining with the nW source file itself.

In that spirit, it would be nice if at least the "context" was to be included in the source file as a translatorcomment node.

Edit: Big downsides are that previewing changes in the GUI is now nowhere possible, and Crowdin doesn't show the original string in the context of source code (something QT Linguist does), which makes it harder to understand meaning especially when using ambivalent words. But I suppose the latter is what the string "context" is meant for.

Also it seems that Crowdin's "context" is being filled with our context nodes. That's not informative enough for translators. I believe the idea according to Crowdin is to use "context" as a descriptive caption for the string, where needed.

commented

Yes, there are some major shortcomings with these tools. The complete lack of proper context is a major reason why I've avoided them. If anyone knows of an online tool that mimics Qt Linguist, I'd much rather use that, but I haven't found one yet. It's nice that it provides fairly good suggested translations, but I do fear the lack of context will result in many inconsistencies in the translations over time. The process of building and loading the translation files is still fairly technical. It was somewhat easier when the file was being edited in-source already.

Qt Linguist is actually a fairly good tool. It's just annoying that it's so inaccessible on Windows.

I'm still a bit uncertain if this is the right move for the project. I'm tempted to revert the last changes. I'm happy for some input here.

commented

I've added screenshots to over half the strings now, which will hopefully help. There are still a bunch of strings related to error messages, notifications, dialogs, and tooltips, that are not on screenshots. But it should at least help show the context in lack of side-by-side view of the source.

commented

@vkbo First of all: thanks for the flexibility towards trying out a new tool like this! 😄 Not everyone is so willing! Secondly, if my initial skim of the past comments was correct: Yes, I am willing to to dutch. I could conceivably also do spanish and german.

Though I don't know if I have sufficient time to spare as there are quite a lot of initial strings to translate. 😄

commented

After reading the last few comments in more detail...

I agree that Crowdin and similar tools are nowhere ideal. However, I am an IT engineer and experienced developer and found qtLinguist not really very nice to use.

  1. It took me quite a bit of time to get it setup properly to start on a Dutch translation; (mostly due to some unclear descriptions in the qtLinguist docs)
  2. I don't like the amount of stuff that needs to get installed just so I can create a translation for one project;
  3. I did not find the context hints of qtLinguist particularly clear nor helpful if I'm being completely honest;

In any case, I personally feel neither option is "the best" for differing reasons. The biggest reason I can think of in favor of a tool like Crowdin and against a tool like qtLinguist is that you don't have to have a lot of IT knowledge or have to have a particular system to be able to contribute a translation if you're using a Crowin (like) tool. It is also much easier to keep track of new or changed strings.

That would open the pool to a (hopefully) much larger pool of translators...

commented

I've reduced the amount of text to translate by about 25%, so the task should be a little lighter. If you have made translations already, you should be able to upload your work. I did it with all the existing translations.

I've already added Dutch and German languages. For German, the JSON file is already translated. Even a partial translation is a good start, and I can hold off on including the new translations for a release or two.

Since there is already Latin American Spanish, I'm not sure there is a need for more variations. Since there is a limit to how many languages I can add, I'd rather not duplicate at this point. I also dropped the secondary version of Norwegian.

Yes, Qt Linguist is a bit too much to set up. Except for on Linux where it's just a dev-tools package. As for running the commands from the setup script, you have to do it anyway to test the translations, but perhaps people don't actually do that. I don't know. I find it hard to say if a translation is good without seeing it on the GUI.

commented

@mvdkleijn @vkbo

Yes, Qt Linguist is a bit too much to set up. Except for on Linux where it's just a dev-tools package. 

Qt Linguist can be found in Pyside2. Just pip install Pyside2 :)

commented

@vkbo I think you will soon find yourself with the burden of updating screenshots only because the strings have changed, even for strings that are related to the one being illustrated (which e.g. imply a contextual change of meaning).

In the end it's about figuring out if your new burden is lighter than the technical burden removed from translators that now don't need to be familiar with using the console, reading source code, doing QA themselves...

By the way Crowdin's machine translation suggestions are not bad at all for Spanish. It's most helpful with long sentences. I'm finding out that it's not always suggesting preexisting translations from changes in the source code, but the MTs usually make up for that.

commented

Thanks for the tip @longqzh!

@tmarplatt, yes, perhaps I will need to update screenshots occasionally, but the interface allows you to replace them in-place and will even try to figure out which strings are still there. So they make it relatively simple to do. It is still yet another thing to maintain, which is why I wasn't keen on using any of these i18n services in the first place.

As for the MTs, yes they are pretty good. I found them very helpful for Norwegian as well. There are a few grammatical errors, but those are easy to fix. It seems what Crowdin gains from allowing open source projects to host for free is that they use our inputs to improve the MT.

commented

If I've done things correctly, the three of you that are in the Crowdin project should now have the access to proofread/approve additions and changes for the languages you are the main contributors of. Since I don't read these languages, it makes little sense that I do this.

That is:

Please check if you can approve translations. I'm not 100% certain how these settings work.

I'll assign Chinese to @longqzh and French to @jyhelle as well when and if the usernames pop up in the list.

commented

@vkbo That's fine. I'll check access tonight. I've already translated the json file and am part way into the main file for Dutch.

I'm sure the translation will need tweaking in the future. I'm for example hesitant whether I should go for a strict, grammatically correct translation or a more colloquial use where English terms are used. The use of English terms like POV is quite common in Dutch.

Anyway, will figure it out. :-)

commented

Sounds good. There are a bunch of terms in English that were picked because they are short and can fit on labels with restricted space like column labels and tabs. For these, it is fine to pick words that convey the same meaning rather than literal translations that take up more space. I've deliberately set max size a few places to prevent squeezing of content due to labels that are too long. There are a few cases of this with Portuguese. The latin based languages tend to be more verbose, so it is a challenge.

Also, please see the comment I added on the JSON number translations. I only added it to "Zero", but it applies to all of them. The capitalisation of the numbers need to match the title case convention of the language. In English, most words in a title are usually capitalised, so the numbers are capitalised too. In Norwegian, for instance, this is not the case, so the Norwegian translation does not have the numbers capitalised.

I noticed you capitalised them in Dutch, so just be aware. If the number word appears at the start of the title, the first character will be converted to upper case by the code, so that situation is handled.

commented

jumping in as I saw some light... I created a Crowdin account and tried to update the French translation.
so far so good, the system seems easy to use (at least from a good will translator's view)

I only have two technical questions (yes, I should probably read some manuals...)
1- the editor seems to strip off the replacement quotes (I mean : Filename '{0}' becomes : Fichier {0}) do we have to force the quotes in ?
2 - the editor inserted many HTML ampersand strings for single quotes marking contraction in text (do not -> don't) which I reverted to regular apostrophe, but now I wonder if that's correct

commented

jumping in as I saw some light... I created a Crowdin account and tried to update the French translation. so far so good, the system seems easy to use (at least from a good will translator's view)

Great! I gave you proofreader permission for French now. You should be able to approve your own translations, and any other contributions made to French by others.

I only have two technical questions (yes, I should probably read some manuals...) 1- the editor seems to strip off the replacement quotes (I mean : Filename '{0}' becomes : Fichier {0}) do we have to force the quotes in ?

The suggestions seem to strip them off I've noticed. I've added them back in. I've used them in the source code where text is inserted so that it is clear the text between the quote marks are referring to something the user has defined. Feel free to use double quotes in the translations, or the «» quotes for French. I use single quotes in the source text mainly because it's simpler in-code, and it is also technically the more common style in British English.

2 - the editor inserted many HTML ampersand strings for single quotes marking contraction in text (do not -> don't) which I reverted to regular apostrophe, but now I wonder if that's correct

I actually don't know. I've replaced them with the proper symbol. They should anyway be encoded correctly when the data is exported.

commented

The Crowdin GUI is so weird when it comes to administration. I have to click through three obscure menus/screens to get to proofread the changes I submitted myself just a moment before. Sorry for the mini-rant. (It's quite decent for everything else.)

commented

Concerning the context field in Crowdin. I believe instead of line number / code references or screenshots, the more efficient thing for both translator as well as admin is to use textual contexts like the examples below:

  • Menu option
  • Right click menu option
  • Login screen
  • About screen
  • Footer entry (max 5 chars)
commented

I don't think there's anything I can do about the context field text. It is generated by the Qt framework. I've added some labels to help describe where things belong, and I've considered adding a few more. But then we're moving into a territory of exactly the maintenance load I wanted to avoid. I appreciate the effort translators make, but having to maintain all of it is a lot of work too.

Another annoying thing about Crowdin is that I cannot promote anyone to help with the work without paying through the nose for upgrading the service.

Edit: It appears I can apply for an Open Source licence. I'll give that a go.

commented

Edit: It appears I can apply for an Open Source licence. I'll give that a go.

I'm sure that will be accepted. Most services like this or build services, etc will have a free for Open Source option.

commented

I don't think there's anything I can do about the context field text. It is generated by the Qt framework. I've added some labels to help describe where things belong, and I've considered adding a few more. But then we're moving into a territory of exactly the maintenance load I wanted to avoid. I appreciate the effort translators make, but having to maintain all of it is a lot of work too.

Well, let's approach it from a different more practical angle then. You keep the maintenance load and effort with regards to Crowdin to a minimum, we as translators will treat translations as work-in-progress items that will probably need tweaking and adjustments after the initial translation was done. In the agile fashion. 😄

commented

Thanks for all the updates for the translations files. I just pulled and merged the ones that were complete. I plan to do the 1.6 release next weekend (Sunday 20th most likely) so I'll do another pull just before the release.

The Spanish translation is just missing two minor new additions. I'll merge it without those. The Chinese translation is a bit more behind, but I'll update whatever is there as well. The Dutch I will include when it is finished as it's a new translation.

If you don't have the time now, there is no rush. I also update translations on patch releases whenever they are ready. I also plan to make more frequent minor releases. Currently, there has been a lot included in each release. Making them smaller means I can get new features out faster, and there's a fairly long backlog of feature requests.

Note: If you want the repository contribution credit for larger translation efforts, feel free to submit the .ts files as pull requests. There is also a credits section for the main translators in the Credits.md file in the source, and in the About dialog inside novelWriter. We need to add you there when your translation is ready, @mvdkleijn.

commented

@vkbo Sorry about the delay, I've been down with covid. I'm nearly back to working order, so I'll try to finish that translation soon-ish

commented

I've been home with a bad cold for a week (negative on covid), so you have my sympathies!

Don't stress with the translation. It's ready when it's ready 😃

commented

@vkbo The Dutch translation is 100% done, but I'm running through it again as a Q&A / consistency check action and accepting or changing translations as I go along.

commented

Great! Thanks a lot for taking the time. I don't have any new patch lined up at the moment, but if there are anything else that needs fixing I'll include it. Otherwise It'll go in 1.7.

As I mentioned above, if you want the contributor credit for the translation in the repository, feel free to download the .ts file from crowdin and submit it as a pull request to the main branch. Then you can also add your name to the about.py file and CREDITS.md file.

commented

I started a localization for German on Crowdin - my first translation project, so I wouldn't want to view anything I suggest as set in stone.

German has two different ways to address people: "Du" and "Sie" -

  • "Du" being informal and familial, also used by modern-day fresh companies who want fewer formalities with their customers and see eye-to-eye. Decreases distance, but has a chance to mildly offend someone (?), especially older folks.
  • "Sie" is the formal, more distanced address between adults who are not friends or who are strangers, and is the standard and widely accepted form of communication between company and customer. It might feel a little clinic?

Is there one you prefer?

I'm unsure of how literal localizations usually are. I've personally noticed time and time again in different pieces of software that the German version was directly translated from English in a way that made it super obvious to me. I'd like to ask some pointers from you as the owner, and perhaps from other native German speakers, about how things are meant to be done. Example:

This area will show the content of the document to be exported or printed. Press the "Build Preview" button to generate content.

I suggested the translation that sounds natural to me:

Dieser Bereich dient der Export- und Druckvorschau. Klicke auf "Vorschau erstellen", um den Inhalt anzuzeigen.

Which translated (literally) back to English is:

This area serves the export and print preview. Click on "Create Preview" to show the content.

Now this of course doesn't sound good in English anymore, but I just wanted to showcase the pieces of information I left out: "document", "button".

Is that okay, or should I stick to the most literal translation?

commented

I do speak a little German, but not enough to decide on the more subtle sides of it. Norwegian more or less dropped the formal/informal distinction over 50 years ago, so it is not something I think about in terms of software either. My suggestion would be to aim for whatever seems to be the convention in German translations in other software. Maybe @Number042 has some input too?

As for novelWriter itself, my preference is that the translated text conveys the same intention rather than being strictly literal. I do that myself with the Norwegian translation. There's a lot of little things that cannot be directly translated from English and still seem natural.

commented

I do that myself with the Norwegian translation.

Thanks for that hint. By translating your Norwegian text I was able to get a lot of context and ideas for the German translation.

I've been using "Sie" for now, but as I'll have to go through all translations again and again anyway, I'd wager it's easily changeable in case you decide for one or the other. I can notify you as soon as the German translation is finished to the best of my knowledge (unless someone else is also looking over it).

Is there a way for me to preview the translations within novelWriter to ensure I assumed the correct context?

commented

Is there a way for me to preview the translations within novelWriter to ensure I assumed the correct context?

Yes, there are instructions for this in the old translation instructions: https://github.com/vkbo/novelWriter/tree/main/i18n

However, it involves building the translation files that the Qt framework needs, which requires the Qt developer tools installed on your computer. The functionality was added by @bkmeneguello, but I'm not sure if it works cross platform. It does work on Linux at least.

commented

Hi @longqzh, I gave you proof reading access on Crowdin. Someone else has completed the Chinese translation, so if you have the time at some point to go through an approve the new contributions, that would be great! You can select "Prrofread" from the menu behind the three dots on the right of each file here: https://crowdin.com/project/novelwriter/zh-CN

It would be nice to update the Chinese translation for 1.7 as well. German is also complete, just needing a proof read. We're almost up to date!

There will be a few changes for each language for 1.7 coming up, but there is nothing major. I've removed a few error messages and added a few labels here and there.

commented

Hi, @vkbo, I finished proof read on Crowdin. will the changes in 1.7 appear on Crowdin automatically ?

commented

Hi, @vkbo, I finished proof read on Crowdin.

Thanks!

will the changes in 1.7 appear on Crowdin automatically ?

No, but I will upload them, and I believe Crowdin sends out an email when there are changes.

commented

Thank you all for your translation efforts! novelWriter is now fully translated into 8 languages. There will be a few updates for 1.7 as mentioned, but it should be only minor changes.

I have also put novelWriter in Mastodon on fosstodon.org: https://mastodon.online/web/@novelwriter@fosstodon.org/108237008264913412

commented

I just uploaded new translations for the 2.0 RC 1 release. There are 95 new strings, however, many of them are just variations or existing strings that has been moved from elsewhere, so translating them is fairly straightforward. I've done so for the Norwegian and US English language files. It took me about 20 minutes for the Norwegian translation.

There are a bunch of brand new ones as well, and I've uploaded or updated screenshots so it should be easier to see where they have been added on the GUI.

Version 2.0 RC 1 will be released on Monday, unless there are any major issues with it. Since this is a release candidate, there is no immediate rush to update the translations. I will merge them as they are ready. There may also be a RC 2 before this version is ready for a full release. There are quite a number of changes affecting many parts of the GUI. However, there will not be much further changes to the translation files.