attract English speaking users (and thus developers) trough improved English localization

il y a 6 ans • mis à jour par il y a 2 ans • 5

Data from http://glpi-project.org/telemetry/ are suggesting strong correlation between localization quality and users count (at least for French and Brazil Portuguese). In result, it mirrors also in nations of developers working on GLPI and its plugins. To gain more traction, it would be very helpful to have English speaking users/contributors (far more than that ones from UK, USA, Canada and Australia) onboard.

Admitting, that for non native English speaker (including me) it is hard to express thoughts in right words, as they are usually used in given context, must say, that English strings in GLPI itself and especially plugins are not in good shape.

As one of translators (namely into Czech), must more than often refer to French and Brazil Portuguese strings to figure out meaning of strings, because English ones are often verbatim translation (example: "waiting value" instead of "expected value", including idioms from developers native languages (example: "thanks to" from French courtesy "Merci ..." in place where is expressed, that user is needed something) and so on.

In result, for English speaking users it is very confusing and is discouraging use of GLPI (and thus potentially contribute).

I know, it is chicken-egg problem - to gain English translators, it is needed to already have native English speaking users first and they almost (in comparison with other _local_ communities) do not exists, because application is not understandable for them yet…

GLPI (especially with its plugins) is wonderful tool – it would be really unfortunate to limit possibilities of its growth due restricting use/development only at local communities instead of global one, for which common language is needed and this language is English (in meaning as medium for communication between people from different precious cultures, not in meaning as of enforcement for unification into one nation/culture to all).

Voter

Réponses 5
Plus ancien en premier
- Plus récent en premier
- Plus ancien en premier

il y a 6 ans

Hey Pavel, totally agree.

I'm creating a localized en-GB.po for a project and finding those little "not quite right" English niggles that you mention. But it's not always obvious whether a term has been incorrectly translated, or is supposed to be that way. For example, I expect that the recurring "Dictionnary" word (e.g., "Dictionnary of computer models") really should be "Dictionary", but as I've not yet come across the label in application use, I'm not making a change.

But the bigger issue is the documentation. The English version seems only about half completed before it collapses back into French (at least, I think it's French). GLPI is not overly complicated to use, but without user guides and admin manuals, the barrier to learning is too high, and potential users give up and move on.

Regards,

Tghu

Répondre
|

il y a 6 ans

Also, small things like the Discussion Forum requiring a delay between searches make GLPI seem very amateurish. It really limits how quickly you can determine whether a question can be answered and the 30 second delay makes it more likely potential users will move along to something else. It's just so old-school:

"Info

At least 30 seconds have to pass between searches. Please wait 14 seconds and try searching again."

Répondre
|

il y a 6 ans

Foremost, thanks you tghuvr for all your work on en_GB localization, thus contributing to solve this problem.

Things like one you mentioned is proof that project of this size badly need lot of development effort to become and stay relevant – nothing not resolvable with enough manpower, which is needed to attract.

Regarding documentation, situation is improving:

http://glpi-install.readthedocs.io

https://readthedocs.org/projects/glpi-plugins

https://readthedocs.org/projects/glpi-developer-documentation/

this one is in process of rewrite, which is done in French

https://glpi-user-documentation.readthedocs.io

Regarding en_GB translation, not sure if non UK based, English (native or second language speaking ones) users will even notice, that there is possible to switch to it. They probably open application with "English" from source code (thus written by non-native speakers), they do not understand, what is application telling them and will end it using.

Nevertheless, in favor of en_uk speaking users, explored situation about localization for them, and result is:

en_GB as a source language (i.e. done by non-native speakers only):

Without en_GB localization altogether (similar to previous):

https://plmlab.math.cnrs.fr/sylvain.allemand/reservation/tree/master/locales
https://www.transifex.com/tsmr/GLPI_resources
https://www.transifex.com/teclib/glpi-project-plugin-escalade
(but is completely localized into en_US)
https://github.com/edgardmessias/browsernotification/tree/master/locales
https://www.transifex.com/teclib/glpi-plugin-uninstall
https://www.transifex.com/teclib/glpi-plugin-itop
https://www.transifex.com/teclib/glpi-plugin-datainjection
https://www.transifex.com/teclib/glpi-plugin-itilcategorygroups
https://www.transifex.com/teclib/glpi-project-plugin-genericobject

Translation opened, but without contributors or incomplete:

https://www.transifex.com/ddurieux/FusionInventory
(this one is really important, without it and alternatively OCS-NG, inventory must be done manually)
https://www.transifex.com/teclib/glpi-plugin-news
https://www.transifex.com/yllen/glpi-project-plugin-behaviors
https://www.transifex.com/teclib/glpi-plugin-plugin-fields
(but is almost completely localized into en_US)
https://www.transifex.com/yllen/GLPI_ocsinventoryng/
(the same as for FusionInventory)
https://www.transifex.com/yllen/glpi-project-plugin-pdf
https://www.transifex.com/yllen/glpi-project-plugin-geststock

en_GB translation almost done:

https://www.transifex.com/yllen/glpi-project-archires-plugin/languages/
https://www.transifex.com/yllen/GLPI_reports
https://www.transifex.com/yllen/glpi-project-plugin-appliance
https://www.transifex.com/teclib/glpi-plugin-order
https://www.transifex.com/teclib/glpi-project-plugin-formcreator

en_GB translation done (was reviewed?):
https://www.transifex.com/teclib/glpi-plugin-tag3
(and is completely localized into en_US)
https://www.transifex.com/yllen/GLPI_webservices
https://www.transifex.com/teclib/glpi-plugin-xivo
(and is completely localized into en_US)

I do know, it is long list thus lot of work (know it firsthand from hundreds hours of work to localize all into Czech), but it would be great to have proper translations into en_GB (and en_US too) to make GLPI sustainable - now GLPI and its plugins are done by very few or even solo developers, so not enough resources for substantial changes into code base and bus factor (https://en.wikipedia.org/wiki/Bus_factor) is pretty bad too (continuity is important factor for decision if deploy such product in production environment)…

Répondre
|

il y a 6 ans

Hi Pavel,

Any open source project potentially suffers from the lack of dedicated resources. Solutions seem to be that the project delivers such a high utility that people are attracted/willing to assist, but I doubt an asset management (AM) system falls into this category. The other option is a paid-for support model, like Red Hat, where the software is open source but the configuration, deployment, and on-going assistance is commercial. I'd suggest that GLPI has scope for this. Any commercial work has to fold back into the open source core, but AM/CMDB is a necessary requirement for an IT team of any reasonable size, so there is definitely a global market. Plug-ins can be similarly supported in this commercial model, even if the code is open source.

However, having worked for an EAMS vendor, my observation is that GLPI is still engineered as a 'development installation', not a 'configuration installation'. That is, to tailor the system beyond anything trivial needs to be done in-the-code, rather than via parameters or with a GUI designer. That's actually a seriously limiting factor in adoption, because it's making the documentation - at every level - more important than it otherwise might be. People are happy to play around with open source, to a certain extent, because it has no license cost so there is no real risk if it does not work out. But if a savvy non-developer IT user can't tweak it without opening the hood and changing code, well then they tend to move on. There are way more configurators than developers, after all.

I'm not sure how that assists the GLPI team, but having looked at the Product Roadmap, it's not obvious that fundamental changes are planned to position GLPI as a competitive platform, rather than interesting but not-compelling software. Anyway, I'm not sure my musings help, but irrespective, I'm certainly glad I found GLPI because it's helping in a project and the only investment has been my time to (somewhat) work it all out.

Regards,

Tghu

Répondre
|

il y a 2 ans

There is a native English (American) speaker on the GLPI development team as of 2020 and we have been fixing some of the little discrepancies in the default en_GB text in GLPI itself and plugins, translated the user documentation to English, and more.

Répondre
|

Service d'assistance aux clients par UserEcho