French Translation

[PatLabGit]

I would like to do the full French translation even the tip of the day when opening Pixelitor, but there is not much help outside going to this one https://github.com/lbalazscs/Pixelitor/blob/master/Translating.md which barely gives 2 files to translate.

Thus my question is... where are the files to translate the full UI?
;)

[lbalazscs]

Hi,

Thank you for your translations! The 3 pull requests are merged now.

Not everything can be translated by simply editing a translation file. Some of the text is "hard-coded". "Hard-coded" text is basically text that's directly written into the program's source code, rather than being pulled from separate translation files.

If there are specific parts of the UI you would like to translate next, just let me know! We can work on adding keys to the translation files for those bits, making it way easier for you to help out without diving into the Java source code.

[PatLabGit]

I would like to translate... All.
I know it's a big task, but French people won't use Pixelitor if it is not fully in French, and your software deserve to be known IMHO, but once it's fully in French, Oh... yeah, they will spread it!

To start, I would say the GUI, what we see when opening an image, the "Tool Options" bar at the top and all the help bubble when hovering a button,

But before starting I need the latest Pixelitor, because the French inside the version I have is not updated to what already existed before I did the pull request (I have the java version 4.3.1).

I'll try what you told me in the Q&A, but I'm not a programmer, nor a "terminal" person.
I would say it's a miracle that I was able to do a "pull request" (my first BTW).

Having said that, I can go thru the code, I understand what is a string which can be edited (I wrote a tinyscript for GIMP, and modified some python scripts for my liking in GIMP), so there is hope that I don't mess up 😉

[PatLabGit]

OK, I did follow your insctuction(downloaded the java file directly from the "Artifact" and it works, Thanks a lot!

Let's translate the full software from now on 👍

If you can point me somewhere like the top "Tool Options" bar for each tool as a starter?

And what is written on the status bar at the bottom, for each tool as well

[lbalazscs]

OK, let's do it!

As a first step, you need to synchronize your repository with the latest version. Currently https://github.com/PatLabGit/Pixelitor is saying that "This branch is 3 commits ahead of, 2 commits behind lbalazscs/Pixelitor:master.". This happened because you started one of the pull requests from your master branch. It's better to create a separate branch for each pull request, but don't worry, it can be fixed. Go to the "Sync fork" dropdown menu and choose the RED option, the one which discards local commits. (Normally this would be bad, but in this case we know that your changes are already merged). After this your master branch on github should be up to date. Now you need to also synchronize your local copy. Normally you would run the command "git pull" to do that, but in this case "git pull" would show an error, so you need to run "git pull --rebase" instead.

Now, let's see those hardcoded strings and let's start with the Move Tool. The source code is in https://github.com/lbalazscs/Pixelitor/blob/master/src/main/java/pixelitor/tools/move/MoveTool.java

The tooltip of the tool button (the hover description) is "Move Tool (V)", but this string isn't in the source code, because it's created from 3 parts: the short name "Move", the string "Tool", which is added to each short name (the "long name" is "Move Tool"), and the shortcut. This is a bit complicated, so let's do it later, and start with something simpler.

If you search for "Auto Select Layer:" in the same file, you will find this code:

        settingsPanel.addWithLabel("Auto Select Layer:",
            autoSelectCheckBox, "autoSelectCheckBox");

We need to change this code so that the "Auto Select Layer:" string comes from the translation file. For this, new key-value pairs also have to be added to at least two files: texts.properties and texts_fr.properties. Let me know if you managed to synchronize your repository and understood it so far, and if yes, I will explain it further from here tomorrow. You can also create a PR for the tip of the day improvements. Don't forget to create a new branch for it (after you synchronized your repo).

[PatLabGit]

Yes I think I understood so far. Surprisingly, the code looks like JavaScript which make me feel a lot more comfortable.

Two things, though:

1. I did not synchronize my "local", because I don't have the code on my computer (if that was your meaning), I worked directly online, which I should not. From now on I will work locally, which one I should download? your master, or the fork I did?

2. I have no idea about git command, nor how to use git locally or to connect to github. I use Atom Editor (now called Pulsar), a little help about connecting it to github would be nice.
   For instance, do I download the zip or in Atom do I pass a command line (if so which one)?

In the end, if I understood correctly, I should transpose this code

settingsPanel.addWithLabel("Auto Select Layer:",
            autoSelectCheckBox, "autoSelectCheckBox");

in a way to match the formatting of texts.properties like below, am I right?

What about this code below? (about the html tags have no worries I know them well, and I suppose that the + between 2 double quotes is to concatenate the strings inside the double quotes? )

public MoveTool() {
        super("Move", 'V',
            "<b>drag</b> to move the active layer, " +
                "<b>Alt-drag</b> (or <b>right-mouse-drag</b>) to move a duplicate of the active layer. " +
                "<b>Shift-drag</b> to constrain the movement.",
            Cursors.DEFAULT, true);
    }

Last but not least,

Don't forget to create a new branch for it (after you synchronized your repo).

How do I create a new branch?

[lbalazscs]

the code looks like JavaScript which make me feel a lot more comfortable

Yes, Java and JavaScript both use a similar syntax.

From now on I will work locally, which one I should download? your master, or the fork I did?

You should do a "git clone" instead of downloading. And you should clone your own repository (your fork), because then you will be able to push changes to it. After you pushed your changes to your fork, you can create a pull request using the web interface. Note that there are many tutorials on the web, such as this one: https://git-scm.com/book/en/v2/GitHub-Contributing-to-a-Project

I have no idea about git command, nor how to use git locally or to connect to github.

There are many online tutorials, such as this one https://git-scm.com/book/en/v2/Getting-Started-The-Command-Line
There are also great video tutorials on youtube, such as https://www.youtube.com/watch?v=BCQHnlnPusY&list=PLRqwX-V7Uu6ZF9C0YMKuns9sLDzK6zoiV . In the beginning you'll have to learn a few new things, but it's not very difficult. Let me know if you have concrete questions.

in a way to match the formatting of texts.properties like below

Yes, in the .properties files there are key-value pairs, the key is on the left, and the value on the right. You have to add new key-value pairs to the default file texts.properties and the French translation file texts_fr.properties. The key can be anything, the value in the default file texts.properties is the English text, and the value in the French translation file texts_fr.properties is the French text.

What about this code below?

Let's deal with these texts later, and concentrate first on the simplest part (the texts on the top part)

How do I create a new branch?

You already created two new branches (patch-1 and patch-2 with the web ui). On the command line you first go to the master branch (git checkout master), and then from there you do a git checkout -b new_branch_name

In the newest commit, I added the key for the "Move:" text in the Move tool. Note how it looks now:

        String moveText = resources.getString("mt_move");
        settingsPanel.addComboBox(moveText, modeSelector, "modeSelector");

Previously it looked like this:

        settingsPanel.addComboBox("Move:", modeSelector, "modeSelector");

In the new version, the "Move:" text isn't "hardcoded" in the Java file. Instead, the Java file looks up the language-dependent string by using the "mt_move" key (the key can be anything, I used the "mt" abbreviation to mean "move tool").
There is also a new key-value pair added to the default file texts.properties and the French translation file texts_fr.properties. In texts.properties you see the original English text:

mt_move=Move:

and in texts_fr.properties you see the French translation:

mt_move=French Move:

Well, it's not actually a French translation, because I don't know the French for it, but if you use the French language, then you should see "French Move:" in the UI, and in all other languages you should see the original "Move:"

As the next step, I propose that you correct the French for mt_move, and also add a translation key for the text "Auto Select Layer:". The key can be anything, I suggest "mt_auto_sel_layer". Let me know if you have any questions! If you get this working, please create a new PR (PR=pull request). Don't forget to synchronize your repository on GitHub first (you will have to do this whenever there is a new commit in my repository.) Your branch is 2 commits behind (because today I added two new commits), and there should be no RED option now when synchronizing (because you are only behind, not also ahead)

[PatLabGit]

OK, some training to start, that's good ;)
Give me one more day or 2, I got a bit busier than usual.

[lbalazscs]

Sure, take all the time you need! BTW, I'm also quite busy this week, so my replies could be slower than until now, but feel free to ask if you get stuck!

[agaqueiroz]

Hi @PatLabGit,

I'm targeting this internationalization changes too. So, how can we work together?
In my experience, the main point is: we can't work on the same file together with git, otherwise the file differences will be difficult to fix. So we need to agree with the works, otherwise time and effort will be spent out.
For now, I found the pixelitor.gui.GUIText and I think that is a good idea to group the texts in there. Finding the texts are the challenge: I'm searching for patterns and using them in regex search on VSCode.

[agaqueiroz]

Guys, this is the sample of the work. Can I keep on? Or do you have any advice?

[lbalazscs]

1. The idea behind the GUIText class was to contain the internationalized strings that are used more than once, in order to avoid code duplication. If you search for the usage of the i18n method, you can see that it's used all over the code directly, without defining constants in GUIText. The key string is already a readable unique identifier, and I don't really see the extra value in introducing constants for the strings that are used only once. CLONE_MSG isn't more readable code than i18n("clone_msg"), in fact I think the second one is more clear, because it explicitly says that this text is internationalized. So I would continue using GUIText only for strings that are used more than once in the UI.

2. In the comments above I said to @PatLabGit to ignore the tool names and tool status bar messages for now:

The tooltip of the tool button (the hover description) is "Move Tool (V)", but this string isn't in the source code, because it's created from 3 parts: the short name "Move", the string "Tool", which is added to each short name (the "long name" is "Move Tool"), and the shortcut. This is a bit complicated, so let's do it later, and start with something simpler

Let me explain in more detail. Obviously the whole "Move Tool" string should be internationalized (not just the "Move" part), but this is a bit tricky. In some languages, the "Tool" part should come first, and in other languages there could be no string between "Move" and "Tool". This means that the current code (which simply appends " Tool" to the tool name) will have to be modified. Let's skip the tool button tooltips for now.

The problem with the status bar messages of the tools is that they can change, if the tools get more features. It's also possible that some tools (selection, pen) will be split up in the future into multiple simpler tools. Any such change would make the current translations incorrect. I don't have a solution for this problem (we want new features and we also want translations), but at least these tool status bar messages should be translated after the simpler stuff.

So my advice is to focus on the simpler messages (note that not even the menus are fully internationalized, check out the pixelitor.menus.MenuBar class), and introduce extra constants in GUIText only if some text is used more than once. And it's great if you don't try to do everything in a single pull request. It's completely fine if you send a PR with 10-20 internationalized strings, or maybe even less in the beginning.

[PatLabGit]

Hi @angalq ,
I'm actually testing and learning how the whole thing works (git, etc...) to not make mistakes and to not PR for nothing (I'm no programmer).

Better I'll let you decide with @lbalazscs what is the best solution/options, and I'll adapt from there, but if we can keep it as simple as @lbalazscs explained over-there > #358 (comment) even in a different way, that would be lovely.

[agaqueiroz]

The idea behind the GUIText class was to contain the internationalized strings that are used more than once [...]

If the text was used once, it can be used over again in some point in the future. With all the text inside GUIText we have a single point of maintenance (Single Responsability Principle). That's the advantage, I think.

But I can start with the simpler messages. In the future, if we agree with that strategy, or other, we can change. No problem.

[lbalazscs]

Think about it - a .properties file is basically just a lot of key-value pairs. And if we had a GUIText class with all the text, it would be the same, just with variables as keys and strings as values. The only (unimportant) difference would be that one would use Java syntax, while the other uses the .properties syntax. So instead of being a single point of maintenance, if would be a second point of maintaining the same key-value pairs. The hard part about maintaining the tranlations is not the simple i18n method call, but making sure that the list of key-value pairs is correct. Right now GUIText is easy to maintain because it has fewer entries, but if we added all those keys, it would be just as long as the .properties file, and we had to worry about new types of bugs (what if multiple keys in GUIText map to the same value?).

If the text was used once, it can be used over again in some point in the future.

Yes, but detecting that kind of duplication in a very long GUIText file isn't any easier than detecting it in a very long .properties file. If in the future we detect such a duplication, we can move the key into GUIText easily. I don't know about vscode, but in intellij idea, this is a trivial refactoring (extract into a constant, then move the constant field into GUIText), a matter of seconds.

I guess we should rename GUIText into RepeatedText or something similar.