Rok,
yes, it makes sense to me. We could do it together with support for module
categories. It can be something like "Module global description". And
categories can be implemented as tags for that description (so you can add one
or many categories to one module).
This information should be owned by a Council of Experts, although module
owners can provide initial information.
Ismael
-----Mensaje original-----
De: [email protected] [mailto:[email protected]]en nombre de Rok Lenardic
Enviado el: sábado, 06 de febrero de 2010 19:11
Para: Ismael Ciordia, Openbravo
CC: openbravo-development
Asunto: Re: [Openbravo-development] Proposed guidelines for naming modules
What if we just add another field for the English Name which can optionally
be entered by the module developer, and at the same time edited by Openbravo in
order to increase visibility of modules?
Rok
On Sat, Feb 6, 2010 at 12:41 PM, Ismael Ciordia, Openbravo
<[email protected]> wrote:
Paolo and all,
my comments on this topic:
a.. A module can declare its native language. It means that the the user
interface of that module is developed in that language
b.. Third parties can develop translations for any module to other
languages. Those will be new modules, and their native language will be the
language in which those modules translate to. It is very easy to identify:
a.. if a module is a translation module (there is a isTranslationModule
property)
b.. if so, what is the module it translates -it should be its only
dependency- and the language it translates to (the native language of that
module)
c.. available translations for a given module (using same info as above)
c.. Of course, if your module's language is English it will be much
easier the translation process since the original text will be in English (most
popular foreign language). So we recommend to use English as native language
but it is not a requirement. For modules in other languages translation to
English will be usually one of the first ones to happen
d.. In my opinion module name should be in module's native language for
consistency with the description above. It should be crystal clear what is the
UI language for the module you are installing, and names and descriptions will
help (although I would also add specific information in the MMC). Translation
modules should use a name/description which is just the tranlated
name/description of the original module
e.. We should add optional filter by language in MMC, so it is possible
to search modules available just in a specific language (although still
possible to do multi-lingual search). I think that at some moment in time the
natural way to browse the Central Repository will be in the system language for
that instance. Clearly, once we have high volumes and enough translations this
way will provide much better experience than multi-lingual searches.
f.. In my opinion current problem is due to quality of name/descriptions
more than languages. How many functional modules -excluding localization ones-
are developed today in languages other than English? How many modules have a
very poor name/description? Maybe we should prioritize an enhancement in MMC so
by default only "good quality" modules with good names/descriptions are
displayed.
g.. In order to have good understanding of what functionality is covered
by modules in the CR I would not force people to name their modules in English
but to categorize them using a centralized list of categories prepared by us
and with a good translation to other languages. That categorization might be
controlled by us -or some privileged community members- to ensure quality. And
that categorization will be really helpful to improve search capabilities in
the MMC.
h.. In some cases -or maybe in all cases- the name is not only the most
meaningful information about that module but also the "brand" for that
development. So it might be reasonable to make it very visible the original
module name and original module logo when displaying translation modules
a.. There are two groups of modules that should not be translated to
English: translation ones and local specific modules only meaningful in a not
English area
a.. In my opinion we should not focus on developers or "Repository owners"
experience (interested in a complete module directory to avoid duplicities) but
on our users experience looking for a particular functionality, and it seems
clear to me that best in class user experience is through user interfaces in
users language (Rob, can you comment on this?). It does not mean that we will
not be able to prepare a complete directory of modules and functionalities in
the CR. It means that it should not be at the cost of poorer user experience
Ismael
-----Mensaje original-----
De: Dmitry Mezentsev [mailto:[email protected]]
Enviado el: miércoles, 03 de febrero de 2010 20:18
Para: Asier Lostalé
CC: [email protected]
Asunto: Re: [Openbravo-development] Proposed guidelines for naming modules
Hi,
As for me having all modules names in English has a benefit of
facilitating collaboration and not having duplicating work (if I see that there
is exist functionality for another country which is very similar to the one I
want I can ask that module developer to adopt it or sth).
Downside could be having too much modules if I look for sth really
available in English (but I guess it is not the case now) and if there will be
module base language filter it will solve it.
Dmitry.
On 3 February 2010 15:44, Asier Lostalé <[email protected]>
wrote:
Hi,
For me it makes sense to have the name and description in the module's
base language. The rationale on doing in this way is:
-I would search for modules using the language I want to install the
module in. If there's a translation for that module in my language, it would
appear in the results instead of the original module. When I try to install the
translation, as it depends on the original module, both would be installed.
-If the search doesn't return any result, I would try searching in
other languages I can work with.
-The problem I could have is that in case there's not translation for
the module, I wouldn't be able to find it. But on the other hand, if I'm not
able to find that module is because it is not translated to one of the
languages I'm able to work with, so I don't see a big benefit on finding it
because I wouldn't install it if I don't understand it.
On 02/03/2010 03:01 PM, Paolo Juvara wrote:
All,
as we have now reached a whopping 115 modules published in the
Central Repository, it starts becoming difficult for end users to find what
they want in the Module Management window. In future, we will add
categorization and better search capabilities but for now we need to rely on
good names and descriptions.
A few months ago, Peter and Gil proposed a set of naming rule but we
never rolled them out. I now re-propose a new set of rules based on their
original work.
If we all agree on these rules, I will add them to the wiki as an
official reference and we will start enforcing them.
The most controversial rule is enforcing the usage of English for
module names (but not for module descriptions - note: the Search function
searches both names and descriptions). The rationale for this rule is to
enforce some consistency and to allow users not knowing the language to know
what the feature is about, even if it is not in their language (think of the
case of a module developed by a Chinese developer in Chinese but applicable
globally - a Spanish user might want to find it and provide a Spanish
translation for this module).
However, I know that not everybody agrees with this rule and possible
alternatives are:
1.. All module names are in English except for the modules that are
a translation of another module. For example, the translation of the Tax Report
Launcher will be called "Generador de declaraciones de impuestos" (I believe
that this is Ismael's recommendation) while the rules below recommend "Tax
Report Launcher Translation: Spanish Spain (es_ES)"
2.. The name of a module is in the base language of the module (the
name of a module in Chinese would be in Chinese).
Please let me know if you have any opinions on this topic and what
you think of these rules
Thanks,
Paolo
----------------
Naming guidelines for modules.
It is important to select an appropriate name for your module in
order to make it easier for users to recognize it both in the Forge and in the
Module Management window.
Here is a set of naming guidelines that we ask module author to honor:
Branding rules:
a.. The module name should match the project name in the Forge
(optional)
b.. Module names should not be longer than 5 or 6 words and less
than 60 character long (optional)
c.. Module names cannot contain the word "Openbravo"
a.. JSON REST Web Services: CORRECT
b.. Openbravo JSON REST Web Services: INCORRECT
d.. Exception to the previous rule: modules that Openbravo S.L.
decides to market as products rather than modules:
a.. Openbravo QuickStart Template: CORRECT
e.. You do not need to specify the Openbravo version in the module
name:
a.. Translation: Arabic Saudi Arabia (ar_SA): CORRECT
b.. Translation: Arabic Saudi Arabia (ar_SA) for Openbravo 2.50:
INCORRECT
f.. Module names should not contain the word "Module"
a.. Copy Role: CORRECT
b.. Copy Role Module: INCORRECT
Language and grammar conventions:
a.. All module names must be in English. The module description and
help can be in any other language.
b.. Non English proper nouns are accepted as part of a module name
specified in English
a.. Tax Report: Modelo 349 (Spain): CORRECT
b.. Tax Report: Form 349 (Spain): INCORRECT (rationale: Modelo
349 is a proper noun and should not be translated)
c.. Informe Fiscal: Modelo 349 (Spain): INCORRECT
c.. The module help must be different than the module description
d.. Grammatically, module names should be consider proper nouns and
you should capitalize the first letter of every word in the module name (with
the exception of short words and acronyms)
a.. Initial Data Load: CORRECT
b.. Initial data load: INCORRECT
c.. Direct Debit Form of Payment: CORRECT
d.. Direct Debit Form Of Payment: INCORRECT
e.. Three Digits ISO Country Codes: CORRECT
f.. Three Digits Iso Country Codes: INCORRECT
e.. You should avoid using numeric characters to express quantities
(they are OK in codes and dates)
a.. Three Digits ISO Country Codes: CORRECT
b.. 3 Digits ISO Country Codes: INCORRECT
c.. Chart of Accounts - PGC 2007 General: Spain: CORRECT
d.. Tax Report: Modelo 349 - Spain
f.. Module names should not end with a full stop:
a.. Initial Data Load: CORRECT
b.. Initial Data Load.: INCORRECT
g.. Module description should end with a full stop
a.. Generador de declaraciones de impuestos. Traducción al
español (español España) del módulo Tax Report Launcher.: CORRECT
b.. Generador de declaraciones de impuestos. Traducción al
español (español España) del módulo Tax Report Launcher: INCORRECT
Specific types of modules:
a.. Core translations (translation of Openbravo Core) should follow
the convention:
a.. "Translation: $LANG $COUNTRY ($CODE)"
b.. Example: Translation: Arabic Saudi Arabia (ar_SA)
b.. Module translations (translations of modules other than
Openbravo Core) should follow the convention:
a.. "$MODULE NAME Translation: $LANG $COUNTRY ($CODE)"
b.. Example: Tax Report Launcher Translation: Spanish Spain
(es_ES)
c.. The description for module translations should include an
appropriate translation of the module name in the target language as well as
both the name of the language and the name of the country in the target
language:
a.. Example:
a.. Name: Tax Report Launcher Translation: Spanish Spain
(es_ES)
b.. Description: Generador de declaraciones de impuestos.
Traducción al español (español España) del módulo Tax Report Launcher.
d.. Chart of accounts modules should follow the convention:
a.. "Chart of Accounts: $COUNTRY"
b.. Example: Chart of Accounts: France
e.. For countries with multiple charts of accounts, use the
conventions
a.. "Chart of Accounts: $TYPE - $COUNTRY"
b.. Example: Chart of Accounts: PGC 2007 General - Spain
c.. Example: Chart of Accounts: PGC 2007 PYMEs - Spain
f.. Tax configuration modules should follow the convention:
a.. "Tax Configuration: $COUNTRY"
b.. Example: Tax Configuration: France
g.. Tax report modules should follow the convention:
a.. "Tax Report: $FORM_NAME - $COUNTRY"
b.. Example: Tax Report: Modelo 347 - Spain
h.. Region modules should follow the convention:
a.. "Regions: $COUNTRY"
b.. Examples: "Regions: Brazil"
c.. NOTE: whenever the regions of a country are called something
other than regions, you can use the correct term in the module description.
Example:
a.. Name: Regions: United States of America
b.. Description: US states.
i.. Report modules (other than tax reports) should follow the
convention:
a.. "Report: $REPORT_NAME"
b.. Example: Report: Shipments Awaiting Invoice
j.. Skin modules should follow the convention:
a.. "Skin: $SKIN_NAME"
b.. Example: Skin: Blue Sea
k.. Tutorial modules (provided as examples to illustrate how to
develop modules) should follow the convention:
a.. "Tutorial: $TUTORIAL NAME"
b.. Example: Tutorial: Solitaire
l.. NOTE: in future, we might use these naming convention to
automatically categorize modules based on tags.
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Openbravo-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openbravo-development
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the
business
Choose flexible plans and management services without long-term
contracts
Personal 24x7 support from experience hosting pros just a phone call
away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Openbravo-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openbravo-development
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the
business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Openbravo-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openbravo-development
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Openbravo-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openbravo-development
