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.
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.
@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.
@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!
@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!
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.
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?
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.
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.
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.
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.
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.
I always thought too that the measurement ts files contained the translations for SeamlyMe, but those are contained in the Seaml2D ts files. So running Lupdate covers both apps.
The measurement ts files are static. I’m thinking to maybe search for “unfinished”, and pick the file with least number for each language- assuming the one with least would have the most translations. Those would become the ts filenames - minus the PMS numbers - to use for each language and the rest can just be deleted.
I volunteer for picking out the ‘best’ translation file. I have already diff-ed the files, giving an overview of what has changed between versions. For the languages I know (English, French, German and Dutch) I think I can judge which file is best. Hopefully there is some logic in the differences (e.g. file p1 being consistently better than p0, which I think is the case) and then we can extrapolate this to the other languages. I can also make a file listing all alternatives per item, so that any past effort is archived and the choice can be improved with the help of a native speaker if need be.
I agree with @Douglas that mapping the names from a book to the standard names is not too difficult. Moreover, as long as you remain within a particular system, it is not even important to choose the right standard term. As long as you remain consistent, you keep a one-to-one relation between the name of the book and the standard name you have chosen. A wrong choice will not have any consequences for your pattern, even though it may make transfer of a pattern to someone else a bit difficult.
Correct mapping of names in patternmaking systems to the standard names is something for the manual, in my opinion. It should not clutter the code.
→ You’re creating one measurement translation file per language, where each file will ultimately contain the translation of all SeamlyMe measurements into that language. These new measurement translation files will replace our current way-too-many .ts files.
→ You’re NOT creating files that contain mappings from patternmaking system measurement names to Seamlyme measurement names. We’ll do this in the future.
@slspencer, yes that is correct. I cannot guarantee that the single file will contain a translation of all measurements at this stage - that depends on how complete the available files are. However, there will be placeholders for translations of all measurements.
And for the second point, my proposition is to make a neat table per patternmaking system that maps the names in the PMS to the Seamly2D standard names, and incorporate that into the documentation and the wiki. You can look up the mapping once, and have it properly done when you enter your measurements. If I understood it correctly, you already have such a mapping table.
Of course, no pressure here. That will happen with time.
I have a LibreOffice database of these mappings. When you start working on this, let me know. I’ll work with you to expand the database – it’s nice because it can generate reports with each measurement’s Seamly diagram.
I would think that each of the 50+ systems has a common base of all the “known” measurements defined in SeamlyMe, with the additions of entries pertaining to the given PMS.
I would think all we need are the known measurements. To be honest I don’t even know if any PMS specific translations have even been implemented past the selection of the PMS in the prefs, and the loading of the PMS / language specific ts file at runtime.
Just a thought… Wouldn’t it be easier to have a basic measurement template for each of these 50 odd PMS’s, to get people started, rather than setting it into the programming? I feel that by reading the book section on measuring and looking at the diagrams, one can quickly choose the correct measurement required while drafting.
