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:
cs_CZ
only 8 translations available. Use p0
el_GR
appr. Half the terms translated. P998 has a few more. Use p998
en_CA
Bizarre: translation from English into English. Drop
en_IN
also English to English. Two versions (p0 and p998) but differences not clear. Drop
en_US
English to English. Drop
es_ES
appr. Half the terms translated. Only p0. Use p0
fi_FI
negligible number of translations. Use p0
fr_FR
three complete translations. P998 seems the best (most consistent, most concise)
he_IL
not a single translation available. Drop?
id_ID
one single term translated in p0. Use p0
it_IT
less than half translated. Only p0. Use p0
nl_NL
Two full translations. Minor differences p0 and p998. Use p998
pt_BR
limited set of terms translated. Only p0
ro_RO
half translated. Only p0
ru_RU
more than half translated. Only p0
uk_UA
one third translated. Only p0
zh_CN
two terms translated. Only p0
de_DE
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.
Update:
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.
