I can do that …
3 Likes
you can add the language to the file share/translations/translations.pro
and create the files seamly2d__.ts
(if you have done the checkout from GitHub - FashionFreedom/Seamly2D: Open source patternmaking software to democratize fashion. )
2 Likes
Do I only translate the translation tag?
Which file i need to translate, seamly2d__.ts or measurements__.ts ?
2 Likes
I believe the seamly2d_ts file is for the interface, & the measurements_ts file is only for the measurements. So, both of them need translated/confirmed as translated, but the seamly2d_ts file probably has priority.
If you open it in Qt Linguist, it has a lovely framework making it clear what needs work.
3 Likes
You should be using Qt Linguist to edit the translations. Don’t directly edit the xml. You can use the standalone version.
Here’s a topic that I went through using Linguist
3 Likes
Both, but you have to be careful with the measurement ts as the measurements have a specific format
Also note that you should name the ts files with the correct ISO locale code… for Croatian it should be seamly2d_hr_HR.ts and measurements_hr_HR.ts. Not sure which code to use for Serbian.
2 Likes
Hi, @Goran
I am currently working (well, at a snails speed, really…) on the french translation. Qt Linguist has a good “user friendly” interface, but I struggle with the fact that I don’t always know where in Seamly’s interface are the chains of character I am translating…
As this is a collaborative work, I guess it is important to keep the same path somehow, just so that the developpers do not have to struggle with too many different workflows coming for everywhere. (And also because I usually do as I am told, at least until I find a better way… which I have not. Yet.)
So I work with Qt Linguist as @Douglas and @Pneumarian advised, but I have to confess I find really useful sometimes to look at the source code with Notepad++, just to be sure that there is no other chain of characters hiding somewhere. But this is just because I know how to do that with Notepad, and not with Qt Linguist yet…
I am working on the measurements.ts file first, because Seamly2D refers to the measurements. Then I’ll work on the seamly2d.ts file.
I was wondering, wouldn’t it be useful to have a “Translater’s Guide” somewhere, not necessarily to fix any “best practices”, but somehow to allow translaters to discuss their practices ? I am sure we could learn from one another…
3 Likes
That’s the “context”… or more specifially which source ui form file. For example… take the DialogAboutApp
It corresponds to the Seamly About dialog, which is generated by the dialogaboutapp.ui file
So if you look at the “source texts”… you will see About Seamly 2D… which is the Dialog title. So any ui text string that’s been checked with the TR attribute, it will generate a translation string when ever Lupdate is run. If new additons are added to the form, a new text string will be generatedin the ts file. If a ui text is deleted, the text string is then marked “vanished”… meaning it’s no longer in the form. One can run Lupdate with an option to remove “vanished” or “obsolete” text strings.
So take the text string “Contributors”… that is the label_contrib_label in the About form. When you look at the form designer in Creator, you will note it’s checked to translate. What happens then when you switch languages, the app then uses that language’s qm file to change all the text strings… so if you were using the Spanish translation the label text is replaced with Colaboradores.
That all being said… while it helps knowing what form a text string is in, it shouldn’t matter translating, unless there may be something ambigous about the text where it helps to see the context. Translators that work throuh a service like Transifex, have no clue what the app is, they just deal with the ts file, whether it’s through Linguist or another app.
2 Likes
Since I did some checking - I need to expand on this… since the measurements are actually variables there are tests that are built and run to check the validity of the locale & translations. The tests will check for things like the system code, locale, comparing the regex of the orginal to translated names, name uniqueness, or if the translation string contains a LF. The tests use a defined list of supported locales… so it’s not just a simple matter of adding a new measurements__.ts file and adding it to the translations.pro. The translation file list also has to be updated with the new locale. If a new ts file is added without updating the list, the test (and build) will fail as the number of ts files does not equal the supported locales. It’s a check to make sure no translation files are missing.
@Goran So… I can handle adding the new locale if you’re not up to doing that.
2 Likes
Well we can use the “translations” category to discuss translation related topics, but it probably wouldn’t be a bad idea to create a doc on how to use Linguist with Seamly and for those inclined how to integrate it with the repo. Which means one has to have an understanding of using Git to fork and create a new branch to do the translations in, pushing that branch, and making a Pull Request to add the changes. And that’s all assuming one has no conflicts with the merging the ts file(s)… which ironically will most likely require one to edit the ts file directly to resolve any conflicts. Which in itself needs a guide on how to setup your editor to resolve conflicts.
3 Likes
I totally agree with you. A guide would be very helpful. I am good with text editors, so this is not a problem for me. This is my first time working with QT Linguist, so I would appreciate any recommendations on what to pay attention to. I will translate for Serbian, Croatian, Bosnian, and Montenegrin languages.
3 Likes
For the Seamly2d files mainly pay attention to punctuation in the text string. The translation tests do check if the punctuation has changed. Also, like the measurement files, I think you need to avoid a LF at the end of a text string… not always apparent in the translation box.
Also, if you care to… you may have noticed the green and grey checkmarks. Grey means a string has been translated, but not marked as done. A Green checkmark means a string has been marked as done… or verified as being correct. Theoretically, the goal is to see all green check marks, meaning every string has been translated.
Also… another reason for using Linguist, is that you can easily see which contexts and strings have been translated by looking for the ones with “?”'s. Which is a lot easier than searching the xml for “unfinished”. Theoretically, though, since you would be adding new languages, nothing should be translated yet.
BTW… you can load multiple languages into Linguist at the same time… not sure if that would be of help for you - thinking maybe some of the strings are similar where you could cut and paste between languages?
Don’t know if you have the Linguist manual, but this may help:
Qt 4.8: Qt Linguist Manual: Translators.
Great. 
Again, just make sure to use the ISO codes in the for the Serbian, Bosnian, and Montenegrin ts filenames. Something else I forgot… the new languages have to be added to the preferences as well, otherwise there’s no way to change language. Also minor detail, while there are flag Icons for Serbia and Croatia, we’ll have to add ones for for Bosnia, and Montenegro.
So do you want to do all the other source code updates, and deal with pushing the changes to Github, or do you just want to send the ts files to me and I can handle the rest? Either way is fine with me, and I can guide you through it.
2 Likes
Honestly, I’d love to send it to you. That would be simpler.
2 Likes
No problem. When you’re done with any of the ts files you can either PM them to me here - you will have to zip them as the forums filters out ts files as attachments, or you can email them to me at:
Thanks for doing this. It will be a nice addition to the application.
2 Likes
Well, at the translations, there are many items which could be improved 
I had opened the german translation file clicked by chance on the first item AddDraftBlock and the german text is not 100% ok – but I think correcting all translations will be a full-time-job
therefore first priority is the software and a correct english text, then the rest.
1 Like
That’s not a text string to be translated… it’s a “context”… which is actually an undo class name and doesn’t get translated.
AddDraftBlock::AddDraftBlock(const QDomElement &xml, VAbstractPattern *doc, const QString &draftBlockName, QUndoCommand *parent) : VUndoCommand(xml, doc, parent) , draftBlockName(draftBlockName) { SCASSERT(draftBlockName.isEmpty() == false) setText(tr("add draft block %1").arg(draftBlockName)); }
Here’s the xml: Only < message > < source >'s INSIDE the < context > get translated. It’s also another reason why I suggest to users unfamiliar with the code NOT to edit the ts files. Use Linguist instead. If you start mucking with the context names the app will not be able to create and apply the qm files properly.
<context> <name>AddDraftBlock</name> <message> <source>add draft block %1</source> <translation type="unfinished"></translation> </message> </context>
It’s already in English… and for the most part I have fixed all the incorrect terminology, and / or made some of the terms uniform… such as “Type of lIne”, “Pen style”, and “Line type” are now all “Linetype” in the ui. Gone is the term “Passmark” and replaced with “Notch”. Plus the grammer has been fixed in many places. All of which is why a good percentage of the translations got broken. RT’s idea was "Don’t change the UI - it will break the translations. So nothing ever got fixed. I never cared about that… like you said get the English correct first. But thanks to work by users we should have a good chunk of the app translated in Dutch, German, French, and Spanish soon.
2 Likes
@Goran BTW… This brings up another point to watch for… this happens to be an arg format string (In this case for the undo string in the AddDraftBlock undo command class.)
setText(tr("add draft block %1").arg(draftBlockName));
It should have been coded like this: (Not my fault)
setText(tr("add draft block") + " %1").arg(draftBlockName));
So that only the text that needs translating is translated. This style I’m sure is throughout the code. So the point is DO NOT CHANGE OR REMOVE any %[num] placeholders, or the format string will be broken and the arg can’t be replaced. More likely it will throw an error during compliling. If we go and change all the format strings now, they would have to all be translated again… which is why I didn’t bother fixing them.
4 Likes
Also have to update src\app\translations.pri and share\translations\measurements.pro
2 Likes