Do I see install screens in own language?! :woohoo: :ohmy:
Installation screens: choose language for wizard [Language] by horus68 · Pull Request #950
I think it would make sense to do what you suggested during the install process. If we do this we will do as you suggested at the same time.
Lots to think about here. To help with new user adoption for SuiteCRM I really want to avoid offering language packs with English for non-translated bits. I would prefer to risk putting a translation that isn’t 100% correct and promote getting a correct translation by its users.
Long term dreaming here. There is another process issue I am getting stuck on with a GitHub approach as folks may PR to that repo and I would like to then get that back into CrowdIn as it does a fantastic job of showing translation progress. But if we are promoting translation edits right from within any SuiteCRM instance then perhaps that isn’t as needed.
Short term, just need a way to list every language pack on the SuiteCRM Store and provide a way to download the zip easily. Looks like there are some usability issues to work out there. Hopefully CrowdIn can iron that out.
Fresh zIp files here:
https://sourceforge.net/projects/suitecrmtranslations/files/
Translations need to be accounted for by a team on each language: they are “proofreaders”.
So translations need to de done in Crowdin (or similar platform).
There is no way I (and other language coordinators) would accept users to upload files to Crowdin directly from their apps without accountability as they would also upload english or will replace previous translated lines and will not use the control tools from Crowdin.
So lets keep this simple.
- Anyone that wants to translate goes to a place X (now SuiteCRM)
- To download they can use the SuiteCRM Store from a controlled GitHUB only for files downloaded with API (Later the language install could end up on a feature with internal link inside the suitecrm instance)
The last major step is for me to figure out how to get an installable zip uploaded to store.suitecrm.com starting from the files you have in CrowdIn. The rest seems solvable.
The English default really gets me and the potential of other non-translated strings such as for any add-ons that get installed. The latter is another longer term goal. Would you be open to using a translation service to get those seeded as a starter? Pardon my ignorance.
I created a CrowdIn account and have a pending join under the SuiteCRMStore account.
How would that work? Like a autotranslated feature?
Crowdin already has that (translation memory from all projects on Crowdin and Bing translations) but translators need to confirm each suggestion.
And this is not a fool proof as many errors requires translators edits!
Approved for Finnish translation team
Definitely a huge undertaking and that is why I really appreciate where you have already taken it. Very impressive.
My thought was to use something like Bing or Google translation tools to auto populate everything not yet translated. From there we at least have a starting point (albeit with many errors). While we can at least distribute a 100% non-English translation, I would see these as also needing review/approval from the translation owners for each language. As that happens we can update the distributed install zips. Going forward we wouldn’t need to do that awkward pre-seed anymore. It’ll be corrections and additions only. It’s simply a way to do away with English.
Please don’t. You can try that for your language and you will find that things gets translated with too many errors that would compromise the name of SuiteCRM as a business tool. Those are not errors, they are things translated the opposite way or in a totally confused way.
To use Google or Bing it must be as a pre-seed and approved by a translator that a proofreader can relate to.
If people don’t have time to confirm suggestions already done in Crowdin, they also will not have time to approve any proposal from outside!
1 Like
Let me just support what horus68 is saying. Machine translation is not ready yet, and much less if you’re translating strings without context.
Crowdin already integrates machine translation, as far as that is possible.
We should just focus on getting enough people into contributing for the translations, the truth is it’s quite easy, once you get the hang of it. Most add-ons will have very few strings to translate. It’s better to leave them in English (at least they make sense) until somebody can work on it. I wouldn’t mind translating a simple add-on even if I wasn’t going to use it…
I understand the limitations of machine translation, but let’s not overstate how easy it is to actually get people to contribute. It’s not and will always be a difficult challenge. But the more we can chip away at the barriers the more likely someone is to contribute.
Here’s the challenge I face. We can’t post and say SuiteCRM has a Greek translation on store.suitecrm.com which is really only 40% translated. The expectation will be that they are installing a full translation. On the flip side, an auto translation will lead to errors potentially be perceived as SuiteCRM not being market ready for their needs. However, we face the risk of losing a potential SuiteCRM user because there is not a full Greek translation available. We can’t just say “here is a translation, but you have to translate the rest to make it usable at some level”. Or even, there isn’t one yet, but you can create one. Bye bye and next CRM up, please. With SuiteCRM adoption being my biggest goal here I would rather put out a 100% translated and 90% accurate translation (or even 70%) vs a 40% translated and 100% accurate translation if it means another business using SuiteCRM. The additional benefit of another user is the potential that they may help us to fix the inaccuracies of the translation down the road.
I don’t think your system will hold… but:
Create double listings and let users choose:
- Human Certified packs (with percentage done)
- Autotranslated (can include certified packs and filled to 100% with autotranslated strings)
Note: If you go for a autotranslated language ONLY it will not be done with me and I will handle the project maintenance.
As for me, i will then go outside SuiteCRM managed projects and maintain just my language pack!
I think this discussion could benefit with inputs from other SalesAgility devs
I think a reviewed system is a must. Can’t be two different systems as no objective is fully met and only adds more confusion and translation issues. My only layer on top of the current system (I love the process you have) is to pre-seed with auto translated labels for every label that is still in English. So each language that you have in the CrowdIn project would be seeded with any labels not yet translated. So if a language is 40% translated then the 60% remaining is the auto translated labels. Only change to the current projects would be auto translating the remaining labels to then be reviewed and corrected if needed by a translator.
Once something like that is ironed out then we can get to realizing the purpose of these translations which is getting SuiteCRM into more hands.
I know I am asking a lot, but I think it is important. Is there a way to alter the translation process from English first to correct translation to instead by attempted auto translation to correct translation?
If not, I suppose we could look at just posting the % translated on the various lang pack listings on store.suitecrm.com, but this may be looked down upon by potential SuiteCRM users and a reason to move on.
Not on Crowdin.
Automatic seed is only available for "Automatically fill in regional dialects - Untranslated strings of regional dialects (e.g. Argentine Spanish) will automatically include completed translations from the primary language (Spanish). "
Other 2 options already in place:
- Show machine translation suggestions
Machine translations (Microsoft Translator, MyMemory) will appear as suggestions for translators in the editor.
- Use the global Translation Memory
Checking this option gives translators access to the Crowdin Global Translation Memory. It’s a huge vault of existing translations contributed by previous projects.
non logged in users can now download zip files
each language zip will have this url:
https://crowdin.com/download/project/suitecrmtranslations/- languagecode.zip
Example for Portuguese (Portugal) pt-PT language
https://crowdin.com/download/project/suitecrmtranslations/pt-PT.ziplanguages available
ar-EG.zip
bg.zip
ca.zip
cs.zip
da.zip
de.zip
de-CH.zip
el.zip
es-ES.zip
es-MX.zip
et.zip
eu.zip
fa.zip
fi.zip
fr.zip
fr-CA.zip
he.zip
hr.zip
hu.zip
hy-AM.zip
id.zip
it.zip
ja.zip
ko.zip
lt.zip
mk.zip
nl.zip
pl.zip
pt-BR.zip
pt-PT.zip
ro.zip
ru.zip
si-LK.zip
sk.zip
sl.zip
sr.zip
sv-SE.zip
th.zip
tr.zip
uk.zip
vi.zip
zh-CN.zip
zh-TW.zipThe correspondence with full names is under the language flag at https://crowdin.com/project/suitecrmtranslations
Jason
I think it’s hard for you, as a native english speaker (I’m assuming that’s what you are), to correctly weigh the kinds of issues other people face in their digital lives regarding translations.
For one, we’re not that worried about English. Everybody learns English in school, some are really bad at it, but they are used to that fact, blame it on themselves, and in general they can get by.
Then, we’re very used to using English in our computers and devices. We all started using computers and mobiles in English, before there were any translations at all. When somebody asks me about a computer problem and I’m trying to give advice, I ask “is your Windows in Portuguese or in English?”, I often get the reply “I’m not sure”! They use it everyday, but they use some apps in English, others translated, and they can’t even recall which they’re using.
So, having an untranslated SuiteCRM is certainly not an outrage, is likely not a deal-breaker, and SuiteCRM currently looks quite well in terms of translations, it looks like a work that is advancing rapidly, one you can trust is going to achieve its goals soon enough.
Then, I don’t think you’re correctly weighing the problem with machine translation. It’s not “90% accurate”, it’s an extremely irritating, misleading, offensive kind of innaccurate. It makes a person feel their being treated like a stupid monkey talking to a machine. A non-translated string generates suspension of comprehension, and people will just investigate, ask a friend, and get on with their lives; but a machine-translated string that is wrong generates confusion, mockery and dislike using the software, and feels extremely unprofessional. It’s the perfect argument for anyone arguing against SuiteCRM adoption at a given company.
If I was Greek, I’d MUCH rather have a 40% translated SuiteCRM (that’t probably the 40% of the suite that people actually need and use) than have a bunch of gibberish confuse me while I’m trying to learn the app and its concepts.
You should have seen the outrage here in Portugal with Microsoft’s first Office translations, which were half human-translated, half machine-translated. It just wasn’t a good enough translation, and people simply hated them.
So, I really have few doubts that your scheme will backfire on you in terms of driving adoption.
Thanks horus68,
I’m going to try to get a proof of concept together now that the zips work.
prg,
I don’t think you understand the challenge that I’m most concerned with. We get many folks coming to our site daily not to find add-ons, but to learn about SuiteCRM and to see if there are language translations. We know for a fact that they are leaving to a different CRM immediately. It’s not worth their time to invest anything at the CRM discovery stage. This is the big picture issue.
I completely understand the challenges of translation. However, it is a larger concern to me that if someone is coming to SuiteCRM for the first time that they don’t have these barriers to entry for their language. Each barrier (can’t find translation, not a complete translation, have to go through an awkward process to contribute, etc) is a dropping off point to go to a different CRM that has their language already supported.
My goal is simply to provide them as full of a translation (verified or not) as easily as possible so as to give them a reason to continue trying out SuiteCRM. The more users we get on SuiteCRM, the more contributors we get in the long term (for translations, product, documentation, etc), the better that SuiteCRM gets which means we all win.
Now that CrowdIn supports zip downloads again I can at least tackle making it easier to discover and install language packs even if they are not complete. That’s a big step 1 to saving these folks.
Hope this makes more sense where I am coming from.
Ok, I see your concern… I’m probably being an idiot here, but I get the feeling you’re looking at this from a “Google Analytics” perspective which is too shallow for the issues at stake.
Let me tell you my story…
I’ve been “adopting” SugarCRM since about 2007. I tried it about 8 different times, installing it, running it, evaluating it, before the current attempt in 2016 which is my first succesful one, which I believe is going to actually be used in the real world.
Why did I fail before? Well, even though I am a software engineer, PHP is not my area, and I am doing this part-time, unpayed, for non-profits. This means that my dedication was always limited, so I just kept getting tripped by all those permissions issues, the application breaking down completely for no apparent reason, not understanding the data model, trying Studio but facing it’s limitations, trying a simple code customization and finding it extremely convoluted, losing hours with outdated, incomplete documentation online, etc, etc. I could go on. BTW, I never bothered with the translations for my language, which only came out this year (thanks to horus68).
Why did I keep coming back? Because it was free and powerful. And after the fork to SuiteCRM, more free and more powerful.
Things began to improve when I found time to really dedicate to this, learn from a book, spend hours debugging, etc. I faced the steep learning curve.
At this point (when I am quite happy with SuiteCRM) I would never recommend it to anyone that couldn’t afford to get some technical help or be willing to work very long and hard to learn it himself.
This is not about captivating web searchers going through a site. Anyone considering SuiteCRM is up for weeks and weeks of web browsing, not just a few minutes.
My point is just that this is so full of hurdles that I don’t believe the language pack thing is going to cost us so many people. Especially because it would set them up for a disappointment at a later stage. The machine translations could be an additional hurdle, and one that people would not always be conscious of. They would just think the product is inconsistent and user-unfriendly, when in fact it was just misleadingly translated.
Just look at so many unanswered questions on these forums, from people adopting SuiteCRM who are completely lost, and getting no answers… that’s where the real adoption battle is, making it feasible and easier for them. I don’t believe inconsistent language packs would help at all.
So, I find all your arguments valid, but for me they just make me conclude that we better get many languages really translated soon; not just the appearance of having them translated…
But I’m ok with you trying your approach if you really believe in it…
(and thanks for everything, you’re a big part of the added value of SuiteCRM!)
We have quite a bit in common. I appreciate the backstory. I think our stories/experiences are the minority though.
The feedback about the translations that we are getting are from direct conversations through our live chat. It’s right from the horse’s mouth. It’s a huge mountain to climb, but it’s critical to keep making SuiteCRM more accessible to the majority of folks that don’t see things like us.
So now the translation “issues” are considered a major problem on adopting SuiteCRM?
- There is no CRM with more then 5 languages 99% translated. For a fact (even SuiteCRm that has only 2 languages on 99%)
- Installing languages usually is not an easy task and developers also do not take time with that.
- Language packs is often incomplete not just on strings but also in language files.
- Almost no developers care to create a master language pack so its easier to people create their own pack ("Oh go on search for language files duplicate and rename them, create an install and so on!)
- Developers don’t take time to clean up language files (duplicated strings, unused strings and so on)
- Many software programs do not care on contributing systems from translators (every time someone says “Go to our github and make a fork”…a translator is dead)
- There is no step-by-step guides for translators
This is the scenario foreign users face on any software.
Same goes here before I created the language packs. Language packs was uncompleted, they created errors on loading SuiteCRM and they was aimed to Sugar. Different language teams (german, Russian) had their own method for language packs. Even Spanish (installed with SuiteCRM and from official github was not completed on strings and files)
I had to learn how to create language pack (I did created a guide for that so others don’t have to do the same errors). I created a system where everybody could join and collaborate, updated and created language packs that work.
But even now language master files are a mess and nobody cares on that. Each version update brings more troubles and solves none. I’ve been making some changes on master files but many PR are waiting, even if they are just “duplicated strings in same file”
So what is the solutions SalesAgility is going to do about this issues? Is there a plan to work on the code parts?
So before making big changes lets not ruin the system that is working now but start to solve issues that are problematic even with the system:
- Clean up master language
- Better english wordings
- Simplify descriptions to reduce the number of words. Technical explanations should be in wiki
- Refactor strings to use only one method for strings = value (actually is a completely mess of different formats on the same file)
- Remove formatting /html/code from translation because that breaks translations and do not allow it for load SuiteCRM
- Optimize the usage of language files by the system (less files, less calls)
So is there a plan to this or is not important?
Note: there are some PR on translations and there are not more because the ones are not approved so users that could be involved on this loose their time there.
Example: I have a PR waiting for so long to allow install SuiteCRM in many languages… not approved or commented!
1 Like