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.
Ich verfolge diesen Feed seid Beginn an und verstehe nicht so ganz den Ansatz. Jeder der mit Schnitten arbeitet, arbeitet nach einem Prinzip - in Deutschland ist es oft Müller & Sohn, wobei ich Guido Hofenbitzer bevorzuge, weil er in einfachen, guten Schritten erklärt.
Schnittkonstruktion ist ein Beruf, den man erlernen kann. Man muss einfach wissen wie man mit Maßen, Strecken usw. umgehen muss und in welchen Verhältnis diese zueinander stehen. Es gibt gemessene Maße und errechnete Maße. Jeder der mit Schnitten arbeitet hat sich im Laufe der Jahre eigene Prioritäten und Herangehensweisen zugelegt, die auf Erfahrungswerten basieren.
Arbeite ich am Kunden mit großen Passformabweichungen oder im Konfektionsbereich usw. sind es hauptsächlich Zahlen und Formeln und die lassen sich leicht übersetzen. Maße, die gebraucht werden sind sehr individuell werden aber immer in den jeweiligen Büchern auch erklärt. Ich persönlich arbeite mit nur sehr wenigen Maßen, meine Schnitte gehen alle über die Brustweite und werden über die jeweiligen Passformklassen an das Model (eng-weiter-Corsage-Bluse-Kleid-oder Mantel) angepasst.
Möchte ich die Schnittkonstruktion auch als Hobby erlernen, geht es nur so, indem mich langsam an den Lernstoff heranzutasten, mit leichten Schnitten beginnen und mich immer weiter in die Materie einarbeite.
Anbei eine Tabelle wie die Modelle in die jeweiligen Passformklassen eingestuft werden und in welchen Bereichen die Zugaben erfolgen. Sie ist aus dem Buch von Guido Hofenbitzer und meine Bibel.
Yes…and yes. No different than me having my own template I can load and use. Hard coding the PMS is / was a dumb idea on many levels. Plus as far as translating all the systems is equally dumb… a user can simply create whatever measurement form of whatever custom named measurements in whatever language they choose… be it English, French… or Klingon. The way I look at it so much time was wasted on the PMS’s and translations that coukd have been better spent implementing features that a pattern maker really needs.
In fact IMO even the known measurements and diagrams are only useful if there was a measurement “form” app (or web page) that end users would fill out with “known” measurements and here’s how to take that measurement. As someone who’s done this as a costumer & pattern maker for 40+ years all the known measurements and diagrams is useless to me… I know how to take measurements and don’t need a diagram.
Here is my analysis of the translations. I have written an R script that parses all the xml translation files, and compares the 56 versions per language with one another. It stores all versions with differences in a file but drops the others. Only a few languages have more than one version, and differences are always minor. Where p998 differs from the others, it is the best one for the languages I can judge. In many instances, however, there is only version p0 and none of the others differs from it. The overview is as follows:
only 8 translations available. Use p0
appr. Half the terms translated. P998 has a few more. Use p998
Bizarre: translation from English into English. Drop
also English to English. Two versions (p0 and p998) but differences not clear. Drop
English to English. Drop
appr. Half the terms translated. Only p0. Use p0
negligible number of translations. Use p0
three complete translations. P998 seems the best (most consistent, most concise)
not a single translation available. Drop?
one single term translated in p0. Use p0
less than half translated. Only p0. Use p0
Two full translations. Minor differences p0 and p998. Use p998
limited set of terms translated. Only p0
half translated. Only p0
more than half translated. Only p0
one third translated. Only p0
two terms translated. Only p0
three complete translations. P998 seems the best (most consistent, most concise)
Three of the languages are actually English. They translate nothing but just repeat the English terms. They can be dropped. Some of the other languages have virtually no translations. I propose to keep the translation files for the time being, but if they do not get filled they may have to be dropped. The basis for the selection of languages is not clear to me.
Differences between the translation files are so minor that I do not think it is worth consulting a native speaker to decide. In any case, I have archived all differences in the translation files and I propose to archive these xls files somewhere in the project files. It is good for history writing…
I will now check the chosen files for punctuation and other details, so that they are valid Qt translation files. That will make them ready once the code does no longer look for 56 files per language.
Easy enough. All I need to know which ts from each language to use - which I think you’ve kinda figured that out. From those I would copy to a new base filename - minus the PMS number - plus the language suffix, and then add those as the only files in the translation project file. That way for now we can keep all the existing ts files intact just in case.
As far as why where are 3 English set of files… I have no clue. I live in Buffalo NY 5 mins from Canada… I can read and understand Canadian English just fine. It more of those color vs colour spelling things. If we’re talking closer to Montreal… well - it’s more like Frenglish. If anything I’d have more of a problem understanding someone from Boston or New Orleans. Lol
Yeah, to paraphrase an editor friend, the main thing is to be consistent in your style choices.
Now, if it was locality options instead of language options, it would make a little more sense, but I still don’t see a need for more than en_US & en_UK, but then I’m a metropolitan Texan by birth. LOL
I don’t even see a need for a en_UK. Just for the heck of it I read a UK glossary of sewing terms and the only one I didn’t get was Bumblebunching… or that mess you get when the bobbin gets all bunched up. Lol Can’t imagine measurement terms would be that different in the UK?
That said, maybe @Grace has some input as I would guess she’s using one of the 3?
As is, no, but I assume the idea had been to have localization presets such as are common at the OS level, in which case it would have a small use. If Seamly ever gets big enough that a SeamlyBook laptop made sense, then we could visit the idea, but until then I think we’re better off with just plain en, at least as far as the Atlantic countries are concerned.
Just some info on how the translations work. Sorry if I’m repeating anything.
To start the process you create a base template for the ts files. For example Seamly2d.ts. This file should be in English, and never contain any translations. It is used strickly to copy and create a new ts file for a given language. So for example to create a French ts file copy the base (this can be done with save as in Linquist) named seamly2d_fr_FR.ts German save as seamly2d_de_DE.ts… and so on for the 18 languages used in Seamly. Want to add a new language… do a save as with the new language. Now running Lupdate on each (seamly2d) ts updates against the code base. Translators can now use Linquist to translate each source text. Running Lrelease takes the ts files and produces the binary qm files that are actually used at runtime or when switching language to translate the literal texts. This happens by a call to the translator loading the qm file for the language in the settings.
So to recap… there are 19 ts files… 1 non translated base file, and 18 language specific ts files used for translations.
Now… as for the measurement ts files. For each PMS there is a base file… starting with measurements_p0.ts… and the 18 actual language files. Repeat from 0 to 54, and add p998 for what ever reason is in that one. So we get 19 x 56 ts files, or one for each PMS times 18 languages plus the base file.
With the app translation language, the PMS is also part of the name… so to use PM system #10 (0 being #1) in Dutch, the app loads measurements_p09_nl_NL.qm as per those settings in the prefs.
So… given the conclusion we’ve come to, all we need is 19 measurement ts files… with the base being measurements.ts (which should contain only source texts for all the known measurements). … followed by measurements_nl_NL.ts… etc. These ts files should contain ALL the known measurements - nothing more, nothing less. We don’t care about any PMS specific source texts nor any of the p0 to p998 ts files… except for taking which ever p** fikes seem to have the most translated text for each language.
So in the end we should have 38 ts files. 19 for Seamly2D/ SeamlyMe and 19 for the known measurements. Then it up to the user to either map a given PMS terminology to known measurements OR to simply create their custom measurements file as per the PMS and their language. I will note though there is a benefit to mapping to the known measurements… when sharing patterns, since the known measurements are stored in the xml in English, users can view the measurements in whatever language they choose. On the other hand custom measurements will not be translated.
Have to keep at least 1. Yes… Qt has to translate English to English. The base file COULD be in another language, but SHOULD be English. CA is Canada. Would have to check what IN is… in any case the en_ US should always stay.
Given that we’re eliminating 19 x 55 ts files having a couple extra English ts files is not such a big deal anymore.
Oh… BTW… the suffix on the ts files indicate the language… such _en for English, followed by the country… such as _US United States… as opposed to _en_CA… English / Canada. That’s why some match like _fr_FR, while others don’t _he_IL. Not sure why it’s not _du_NL - assuming you speak Dutch in the Netherlands?
Using _p0_nl_NL… It’s the one you edited and that’s in the commit.
Also since I had to create new qm files… I just loaded all 18 ts files in Liguist… guess what? It will compare the files by displaying a list table checkmarking whether a given file contains a source text or not. Theoretically every column and everyrow should be checked. Otherwise a ts is either missing a known measurement or contains non known measurements that we don’t need.
All fixed. Changed the translatiobs loader() & deleted all the extraneous ts files except the base ts and the 18 languages. Checked switching between languages in SeamlyMe and seems to translate fine. Will check tomorrow eve all the ts files that they all contain all the known measurements, and if there are any issues in Seamly2D with the translations, and we can put this one to bed.
Hmmm… Yes, I grew up in a recently republicized British colony back in the 60s, so all of my education was in UK English and I really have trouble with colour vs color. However, there remain 2 arguments in this instance…
Since I grew up with UK English, it’s really nice to have that option available in the system so that I’m clear in what I want and my sensiblities, that were drilled into me in the 60s, aren’t offended.
The whole internet (and even South Africa, since 2000) seems to have migrated to US English. Most annoying, but such it is and I have to live with it.
So, personally, I’d like to have the option of both UK and US English.