Isma, that is a good suggestion!
Rok
On Sat, Feb 6, 2010 at 8:10 PM, Ismael Ciordia, Openbravo <
ismael.cior...@openbravo.com> wrote:
> 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:* spuzv...@gmail.com [mailto:spuzv...@gmail.com]*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 <
> ismael.cior...@openbravo.com> wrote:
>
>> Paolo and all,
>>
>> my comments on this topic:
>>
>> - A module can declare its native language. It means that the the user
>> interface of that module is developed in that language
>> - 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:
>> - if a module is a translation module (there is a
>> isTranslationModule property)
>> - 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)
>> - available translations for a given module (using same info as
>> above)
>> - 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
>> - 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
>> - 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.
>> - 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.
>> - 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.
>> - 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
>>
>> 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
>> 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:dmitry.mezent...@openbravo.com]
>> *Enviado el:* miércoles, 03 de febrero de 2010 20:18
>> *Para:* Asier Lostalé
>>
>> *CC:* openbravo-development@lists.sourceforge.net
>> *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é <asier.lost...@openbravo.com>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:
>>>
>>> - The module name should match the project name in the Forge
>>> (optional)
>>> - Module names should not be longer than 5 or 6 words and less than
>>> 60 character long (optional)
>>> - Module names cannot contain the word "Openbravo"
>>> - JSON REST Web Services: CORRECT
>>> - Openbravo JSON REST Web Services: INCORRECT
>>> - Exception to the previous rule: modules that Openbravo S.L. decides
>>> to market as products rather than modules:
>>> - Openbravo QuickStart Template: CORRECT
>>> - You do not need to specify the Openbravo version in the module
>>> name:
>>> - Translation: Arabic Saudi Arabia (ar_SA): CORRECT
>>> - Translation: Arabic Saudi Arabia (ar_SA) for Openbravo 2.50:
>>> INCORRECT
>>> - Module names should not contain the word "Module"
>>> - Copy Role: CORRECT
>>> - Copy Role Module: INCORRECT
>>>
>>> Language and grammar conventions:
>>>
>>> - All module names must be in English. The module description and
>>> help can be in any other language.
>>> - Non English proper nouns are accepted as part of a module name
>>> specified in English
>>> - Tax Report: Modelo 349 (Spain): CORRECT
>>> - Tax Report: Form 349 (Spain): INCORRECT (rationale: Modelo 349
>>> is a proper noun and should not be translated)
>>> - Informe Fiscal: Modelo 349 (Spain): INCORRECT
>>> - The module help must be different than the module description
>>> - 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)
>>> - Initial Data Load: CORRECT
>>> - Initial data load: INCORRECT
>>> - Direct Debit Form of Payment: CORRECT
>>> - Direct Debit Form Of Payment: INCORRECT
>>> - Three Digits ISO Country Codes: CORRECT
>>> - Three Digits Iso Country Codes: INCORRECT
>>> - You should avoid using numeric characters to express quantities
>>> (they are OK in codes and dates)
>>> - Three Digits ISO Country Codes: CORRECT
>>> - 3 Digits ISO Country Codes: INCORRECT
>>> - Chart of Accounts - PGC 2007 General: Spain: CORRECT
>>> - Tax Report: Modelo 349 - Spain
>>> - Module names should not end with a full stop:
>>> - Initial Data Load: CORRECT
>>> - Initial Data Load.: INCORRECT
>>> - Module description should end with a full stop
>>> - Generador de declaraciones de impuestos. Traducción al español
>>> (español España) del módulo Tax Report Launcher.: CORRECT
>>> - 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:
>>>
>>> - Core translations (translation of Openbravo Core) should follow the
>>> convention:
>>> - "Translation: $LANG $COUNTRY ($CODE)"
>>> - Example: Translation: Arabic Saudi Arabia (ar_SA)
>>> - Module translations (translations of modules other than Openbravo
>>> Core) should follow the convention:
>>> - "$MODULE NAME Translation: $LANG $COUNTRY ($CODE)"
>>> - Example: Tax Report Launcher Translation: Spanish Spain (es_ES)
>>> - 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:
>>> - Example:
>>> - Name: Tax Report Launcher Translation: Spanish Spain (es_ES)
>>> - Description: Generador de declaraciones de impuestos.
>>> Traducción al español (español España) del módulo Tax Report
>>> Launcher.
>>> - Chart of accounts modules should follow the convention:
>>> - "Chart of Accounts: $COUNTRY"
>>> - Example: Chart of Accounts: France
>>> - For countries with multiple charts of accounts, use the conventions
>>>
>>> - "Chart of Accounts: $TYPE - $COUNTRY"
>>> - Example: Chart of Accounts: PGC 2007 General - Spain
>>> - Example: Chart of Accounts: PGC 2007 PYMEs - Spain
>>> - Tax configuration modules should follow the convention:
>>> - "Tax Configuration: $COUNTRY"
>>> - Example: Tax Configuration: France
>>> - Tax report modules should follow the convention:
>>> - "Tax Report: $FORM_NAME - $COUNTRY"
>>> - Example: Tax Report: Modelo 347 - Spain
>>> - Region modules should follow the convention:
>>> - "Regions: $COUNTRY"
>>> - Examples: "Regions: Brazil"
>>> - NOTE: whenever the regions of a country are called something
>>> other than regions, you can use the correct term in the module
>>> description.
>>> Example:
>>> - Name: Regions: United States of America
>>> - Description: US states.
>>> - Report modules (other than tax reports) should follow the
>>> convention:
>>> - "Report: $REPORT_NAME"
>>> - Example: Report: Shipments Awaiting Invoice
>>> - Skin modules should follow the convention:
>>> - "Skin: $SKIN_NAME"
>>> - Example: Skin: Blue Sea
>>> - Tutorial modules (provided as examples to illustrate how to develop
>>> modules) should follow the convention:
>>> - "Tutorial: $TUTORIAL NAME"
>>> - Example: Tutorial: Solitaire
>>> - 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
>>> listopenbravo-developm...@lists.sourceforge.nethttps://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
>>> Openbravo-development@lists.sourceforge.net
>>> 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
>> Openbravo-development@lists.sourceforge.net
>> 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
Openbravo-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbravo-development
