I have used Qt 5 Linguist to translate the seamly2d_nl_NL.ts Dutch locale file. Dutch is my mother tongue. Translating with Linguist is comfortable and easy, but it was still quite some work. How should I proceed? I have no experience in creating a pull request, do not even know if I can create a branch for that. Can anybody give me instructions?
Hi @peterh
Thank you very much for this. Unfortunately, I’m also all at sea, so @slspencer or @Douglas will need to explain how to do this 
1 Like
Hey Peter… if you want you could just email me (dscaskey@gmail.com) the dutch .ts files( or maybe even just attach them here in a pm?) , and I can save you having to deal with creating an issue, creating a beanch, uploading changes and then creating a PR etc.
Or if you wish I can take you through the process on how to create a branch, pushing changes, creating a PR etc.
BTW… I assumed you forked the project? Normally to create branches on the main you have to have permissions… but you can do it on your fork / local and make a PR from there which can be pulled into the main.
2 Likes
Hi Douglas, thanks for the reply. For the time being I just cloned the github repository to a local drive, where I edited the file. I was unsure about branches, because I did not see any other branches. Now I understand every body is forking, and then creating a pull request from the fork. I think I will try and do that too, just to have something in place. If it does not work, I can always email the translations file but it is also fun to try and do it the proper way! I only translated the dialogs and all the recent changes, not the measurements. I think these are mostly up to date for Dutch. You may see my pull request appear one of the coming days, … or receive an email if I give up.
2 Likes
Absolutely.
Since you’ve edited the files outside of Git and the version control… it’s a bit of cart before horse.
What I would do… or basically what I’d have to do… is make a copy of your ts files. Then I’d start from scratch. 1) Setup a Github account. 2) Install Git in some way - there are several options 3) I’d install a client to use with Github… I just use Github Desktop. 4)Fork the repo. 5)Clone the main and fork - which will allow to access either remotely or locally.
Now that you would have an upto date local… you can create a branch based on develop. You could then copy the backup ts files (which may need to be merged with the current ts files - i don’t know if any tr() changes have been made since you edited the ts fikes?) the new local repo. From there you can push the new branch with changes to either the main or fork- depending on which you have currently set as orgin… and the branch is now created on the remote. Again to push to the main you have to gave permission, on your fork you can do what ever yiu want. Desktop will automatically ask if you want to create a PR… or you can do that at any time. Creating a PR basically means the changes can be merged from one branch to another… in this case from your new branch to either your develop or the main develop - which is the branch weekly releases are built on.
At any rate… there’s a learning curve, I’m sure I’ve left something out, but if you get stuck give a holler.
2 Likes
I think I more or less did all that. I already had a github account, but rules are tighter now so I had some hassle with permits and keys. All done and I think I have filed my pull request. Not entirely sure, however, if that arrives at my fork or at the main Seamly github. I will see, but it is too late now to continue. Tomorrow more.
2 Likes
Just got the email notification… for the main repo.
I’ll check it out tonight
2 Likes
Just a few PR notes… create an issue first that the PR can be linked to. Also if you notice off to the right side bar you can select someone(s) to review the PR… like Susan or myself. You can also select labels as to what the PR pertains to - I set them to translations and ui. If there is an issue or issues for the PR you can link those to the PR so when / if the PR is merged, those issues are closed. I also add in the PR text at the bottom Closes issue # nnn.
2 Likes
PR failed. I suspect it’s because the ts file you edited is outdated.
That’s why I said the edited ts file probably needs to merge with the current ts. It’s why you need to keep your local develop branch current, and one of 2 things has to happen.
- You create a new branch from the most up to date develop branch. Make and push your changes.
2)Merge the current develop into the branch you want to push, THEN push the changes. Merging may require - and in this case most likely will even though it said there were none - conflicts to be resolved before develop can be merged.
You can do the opposite - which is what would probably happen in this case if we tried to merge… you’d have to resolve the conflict’s. Or worst case we mess up the main develop branch too. No bueno. It’s just easier fixing any conflicts before making a PR, then you’re not stuck online trying to fix it.
1 Like
Update:
Here’s what you probably need to do… on your local create a new branch - name it whatever. Switch back to develop. Then you either have to set your origin to the main repo and pull the main develop to your local OR you need to make a PR to pull from the main to your (remote) fork to update develop there. Then you can pull your fork develop to your local. In either case, once your local develop is upto date, you then merge develop into your new branch. Then you have to run Lupdate. This will parse the code and update the ts files… in the process removing any tr() strings that no longer exist, while adding anything new. Now you should have an upto date ts file you can either just recommit that to the PR, or translate it futher for the new changes I know are in there, then recommit.
Also just to put it out there… I’m currently working on overhauling the dialogs and Properties Editor (for the 3rd time - 1st was on my private fork, 2nd as part of feature updates I lost in an HD crash)… so there’s probably going to be a lot of ui text changes. Yeah, I know it sucks, it should be the last time of major changes to the existing ui. After that we only need worry any new additions.
2 Likes
@Douglas, I have tried to follow all your advice. Made a branch, run lupdate in the branch (which rewrote all language files, but only of seamly2D, not seamlyME), checked the Dutch translation file (to see that I had actually been working on a very recent file - everything was neatly translated). Subsequently I committed all changes to the branch and merged it with my local main. No errors reported in the merging. The main was then automatically linked to the still outstanding pull request. On my local, I have built the program and run all the tests, including the very long translations test. No errors were reported. I am hopeful that it will work now, but with some doubts because I do not think I have change anything substantial compared to yesterday.
3 Likes
@peterh all good, the failures yesterday in the CI (after your update) were a github internal error (brownout of ubuntu 18.04), nothing to worry about for you. Your translation update is awesome, and I could merge it now, so all good. Thanks again for your great contribution!
1 Like
@csett86 , thanks for finishing the job so swiftly. When resolving the last errors, I was confronted with seamingly random errors in the translation files of the measurements, even though I had not touched any of these files. All of a sudden, file number 17 of Romanian produced failure of the checks, and when that was resolved it was file number 36 of Dutch giving problems, and a few more. I tried to understand why we have 56 versions of the translation file per language, so around 1000 files in total. Most of these files are identical to one another. In most languages (but not all) files 0 and 1 are different in details, e.g. punctuation and sometimes translations too. In all languages, file 998 is different because the program context is part of the xml, but the translations are similar to most of the files. And then in almost all languages, a seemingly random subset of files differs from the previous and the next in the series. Differences are often minor, but I really cannot understand whether there is a pattern in it. For maintenance and updating the translations, a single file per language is absolutely needed. Like it is now, there is no way you can update it. Curious what is behind this!
1 Like
Running Lupdate reads the .pro file(s) and produces the ts files… for each language. In the case of measurements.pro
PMSYSTEMS +=
p0 p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 p16 p17 p18 p19 p20 p21 p22 p23 p24 p25 p26 p27 p28 p29 p30
p31 p32 p33 p34 p35 p36 p37 p38 p39 p40 p41 p42 p43 p44 p45 p46 p47 p48 p49 p50 p51 p52 p53 p54 p998
LANGUAGES +=
ru_RU
uk_UA
de_DE
cs_CZ
he_IL
fr_FR
it_IT
nl_NL
id_ID
es_ES
fi_FI
en_US
en_CA
en_IN
ro_RO
zh_CN
pt_BR
el_GR
Do the math and thats how many files there are.
Any time a tr() in the ui changes, running lupdate will generate changes in each of the ts files. It’s not likely much is going to change in the measurement files at this point… most changes are going to occur in the Seamly ts files.
I have no answer why random changes occurred in any measurement ts files. 
And that’s why I added a noTranslations option in the pro file… it can take an extra minute or 2 building in Creator as it copies or as the case is doesn’t copy all those files 1 by 1 - which will not change unless lupdate is run.
1 Like
But still out of curiosity, as I am also relatively new to the project: Why are there 56 different translations options (one per measurement system) set up if in practice they are all the same, apart from punktuation? Maybe I overlooked something there? @slspencer can you help me understand this?
1 Like
You’d probably have to ask the original dev RT. I can say this though… the measurement translations are not your standard tr()'s in ui forms or code… it’s all specifically coded for use in the formulas. In fact the vit measurements are saved in English, and are translated on the fly. Probably one of those can o worms left alone.
Other than the measurement I added a few months back from a really old issue, I don’t think the measurement tr()'s have changed in 6 years. The Seamly2D tr()'s are probably what we should be concerned with. I would be concerned though with why a few translations for Peter randomly changed without intentionally being changed.
1 Like
The number of our measurement translation files is the number of languages multiplied by the number of patternmaking systems. This is pure bloat. We need to separate Translations from Patternmaking Systems
Backstory: I wanted users to easily use patternmaking system books and use the measurement names used in the books. I submitted to RT the mapping of 56 patternmaking systems’ measurements to Seamly’s measurements. RT decided to connect the patternmaking systems to translations, and I couldn’t talk him out of it. We aren’t able to use the patternmaking system’s names in formulas, which was the whole purpose of this feature. This is why translators have to translate 56 measurement files into each language, for no benefit to the user.
SUGGESTED TRANSLATION SOLUTION:
* We have only ONE translation file per language for translating the measurement names.
* The user sets their translation file in Preferences (which they already can do).
* The translation filename, or the language, is specified in the .val file.
* When a formula contains translated measurement names, they are processed similarly to custom Variables.
* In SeamlyMe, the variable names shown are the translated names.
SUGGESTED PATTERNMAKING SYSTEM SOLUTION:
* In Preferences, the user can select a patternmaking system (which they already can do, but it does nothing.)
* When a pattern is created, the user can check whether to import the patternmaking system custom Variables. The user can then enter into formulas the patternmaking system variables instead of Seamly measurement names, and follow instructions from books more precisely.
* In SeamlyMe, add patternmaking system features:
* When creating a new measurement file, add a checkbox for whether to use the preferred patternmaking system template.
* Enable setting a font color for the patternmaking system measurements to highlight them.
* Add a checkbox for 'Add Known' and 'Measurement Diagrams' to show ONLY the patternmaking system measurements.
* Add a checkbox for measurement files to show ONLY the patternmaking system measurements.
* Add a checkbox for measurement files to add any missing patternmaking system measurements (with Zero value) to an existing measurement file.
@Douglas, if you could write down, however informally, how Seamly’s translations are implemented, and add your own suggestions how it might be fixed, we could find someone to clean this up.
1 Like
Why do I feel not surprised? Now I understand what RT did, and I get Peter’s point. I would concur it’s bloat. Ironically RT tried creating a script to attempt to use 1 ts…because apparently he also found 50+ files unwieldy. While I can understand the idea behind using the measurement terms used in each particular PMS, it’s just not realistic. In the 40+ years I’ve been doing costumes and patterns we’ve gotten untold measurement forms using various terminology. I can say with complete certainty that I’ve always been able to tell which measurnent is which whatever a client called it. IMO if a pattern maker can’t figure out which measurements in a PMS correlatate to the defined measurements in Seamly, they should find a different vocation - it’s not rocket science.
Sure. Will probably take a few days over the next week.
2 Likes
Actually I looked through the code and it will just be quicker for me to fix and decouple all the multiple measurement ts files than try to explain how to do it.
The main question would be to decide which measurement ts file for each language to leave? At this point does it really matter which as long as it contains the list of “known” measurements? I would assume preferrably the ones that contain the most translations.
3 Likes
Thank you Susan for the explanation! And then yes, I agree fully with @Douglas, we can reduce the translations file to one per language for the measurements, and just use the one that is translated the most.
1 Like