41
irmtfan
Re: XOOPS 2.6 Internationalization/Local support
  • 2013/1/6 4:06

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


Thank you trabis for your helpful comment.
Quote:

We should translate expressions, not single words.

You are right. IMO we need a balance. Single words are as bad as long (sometimes very long) expressions.
Im agree with you but we should do it wisely based on a standard. eg: only Placeholders should be allowed. (no html should be allowed in definitions.) Also long expressions should not make template customization very hard. (As you can see below sometimes I just need number of user posts to play with it.)
IMO that WP standard is important otherwise module developers will add everything in definitions.
Quote:

I agree with the others, just not this one.

very good. I'll Look forward to see the progress. there is some important features specially INI Files.



42
trabis
Re: XOOPS 2.6 Internationalization/Local support
  • 2013/1/6 17:25

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:

DCrussader wrote:
From bad to worst (Nuke to WP), let's make it like Drupal, it's a solid-rock CMS which no one use from ages, the only CMS which uses NODE instead of Article, well 2nd using Weight instead of Ordering, Taxonomy Term for Sub-category, and adding GNU Gettext.

I think you misunderstood me. I'm not looking after WP way of doing translations. But I think the standards they propose can be applied to Xoops.

Quote:

X-1.0.zip downloaded %1s (one download)
X-1.0.zip downloaded %2s (many downloads)

Seems you agree with using placeholders.

Quote:

2nd point - no idea what for will be used as language files, INI, POT, PHP or something else ? How much alphas will go out ?

It does not depend only on me. I'm thinking seriously on using INI files and have the code using it on alpha3. Perhaps the translate class and some demos can be release on alpha2, for review.

Quote:

3rd.....
Several different threads are opened for 2.6 without mentioning simple task tree:

I find organization a very complex subject. The core team is working very fine without using 'simple' tasks. We have pending simple tasks on sourceforge for years now.

Quote:

Quote:

- use html2pdf in extension "pdf" (http://html2pdf.fr/en/default)


How the decision was taken for this ? XOOPS was "community driven", where was the Poll regarding all alternatives ? I think something like this was used in J! 1.0 and removed by own class in 2.5, so the users can make PDF of any content type from the sites in Cyrillic.

htm2pdf contains the tcpdf library so the core team thought it would be a good addition. We can't discuss every subject with the community. If this library does not work on Cyrillic sites we will definitely look for other solutions. We are on alpha stage, we did not test this library on all contexts and we do expect users to report problems.

Quote:

Quote:

- In order to easily add content "out of the box" .


This means nothing - content like the default option in Baned CMS ? Wow if is this, amazing, just amazing....

I can't tell if you are being sarcastic. Since 'page' module is delivered with the core package it will allows users to publish pages without having to look around for content modules.

Quote:

Quote:

- This system allow to create all kind of menus.


Simple Menu Manager or something like Solo Menu module ?

Something like Solo Menu module. It is a refactoring of Mymenus module which was based on the multimenus module by Solo.

Quote:

File Manager/Image Manager ? Maybe in Alpha 5 on random pick without votes ?
Content/Blocks editor - SC, tinyMCE (yack), CK, default used in XOOPS 2.5 ?

Image manager will be just a "move from core to module". We will be looking at features at latter stages. Being modules/extensions, other developers can deliver their own versions which can latter be used as the official module.
I don't know which editor we will be using has default.

Quote:

Alpha 3 looks like Beta 1
And Final 2.6.0 around Christmas 2013 or Q2 of 2014.... (but better late, then never )

We are aiming for latter dates so we don't disappoint the community. I hope we can do this faster then the roadmap suggests.

Quote:

Won't mention my favorite - Sign up/in, Weight and a lot of other termins not used anywhere else except in Drupal/XOOPS 2.5/WP, which making system not only "non-user friendly" but also not understandable...


I think we will be able to deliver a more user/developer/translator/designer friendly XOOPS. And by 'we' I mean users/developers/translators/designers.

43
trabis
Re: XOOPS 2.6 Internationalization/Local support
  • 2013/1/22 20:23

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Hi there,
I'm currently working on refactoring language definitions and I'm looking for help regarding problems you face during translations.

I wish to know special cases where the current definitions cannot be correctly translated into your language.

For example, I already know that the user gender can be a problem when you want to translate 'User %s has %s posts", or "You are registered!"
I also know that concatenation for "%s minutes" and "ago" should not be used because the order of "ago" is important. Instead we should use "%s minutes ago".

In Portuguese language, most of the times I can get around the gender issues by making the translation fit both genders, and when not possible I can append '(a)' to fit the female gender, ex:"Obrigado(a)" => Thanks. Is gender really important in other languages? If so, can you give me more examples where you cannot get around the gender issue?

Strings with ":", for example "Number of posts:", does the ":" need to be in the translation or can it be concatenated by the developer? I imagine it is required to be in the string for RTL support, please confirm.

Plural forms, in portuguese/english we can use something like "Has %s post(s)" when we are not sure if the number is plural or not. Is this possible for other languages also, or plural forms can be very different? Please give me examples of definitions that should have plural form support.

Thanks


44
Anonymous
Re: XOOPS 2.6 Internationalization/Local support
  • 2013/1/22 21:52

  • Anonymous

  • Posts: 0

  • Since:


I can't reproduce examples now but most difficulties when translating arrise when strings are used on more then one place. In some cases an English phrase or word cannot be used in a different context where it is no problem in the original language. Avoiding similar language strings at more places might be translator friendly but can be a pain in the ass in some cases.

45
trabis
Re: XOOPS 2.6 Internationalization/Local support
  • 2013/1/22 22:29

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:

flipse wrote:
I can't reproduce examples now but most difficulties when translating arrise when strings are used on more then one place. In some cases an English phrase or word cannot be used in a different context where it is no problem in the original language. Avoiding similar language strings at more places might be translator friendly but can be a pain in the ass in some cases.


In Portuguese I have problems with single words.
TEXT used in "article text" is different than "text a friend".
In this refactoring I'm prepending A_ (action) on single words that are also verbs.
The keys are also being extended to provide
Here are some of the conventions I've applied so far:
Quote:

/**
* Naming conventions
* - All translations must be enclosed with ""
* - All translations must start with Uppercase, do not use CamelCase
* Good ex: "User groups"
* Bad ex: "user groups" or "User Groups"
* - All keys must be as descriptive as possible.
* - All keys must use complete words between each '_',
* - Keys should be prepended with identifiers in following cases:
* F_ Formatted, use this when strings are parsed with sprintf()
* A_ Action, use this when using a single word which is a verb
* S_ Success, use this for success messages and exclamations
* E_ Error, use this for error messages
* C_ Colon, use this when string ends with a colon ":"
* Q_ Question, use this when string is a question
* - Chain keys alphabetically with the exception of F, F always comes in last
* ex: SF_ (formatted success message), EF_ (formatted error message)
* - Special cases:
* CONF_ Configs, prepend this for your module configs.
* Config keys are stored in database, try to make them as short as possible!
* _DESC Description, append this for configs description
*/


46
Mamba
Re: XOOPS 2.6 Internationalization/Local support
  • 2013/1/23 1:22

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


There are tons of materials on "gender" and "plural" in translations:

http://www.gramps-project.org/wiki/index.php?title=Coding_for_translation
http://www.mediawiki.org/wiki/Manual:Messages_API
http://forum.kohanaframework.org/discussion/6833/i18n-module-for-kohana-3/p1
http://nedohodnik.net/gettextbis/index.html
http://www.gnu.org/software/gettext/manual/gettext.html

Maybe you'll find something useful. If possible, it would best to pick one established standard for gender/plural related issues (like in Gettext) or something similar, and use it consistently, so we could always forward people there to study it, if in doubts.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

47
irmtfan
Re: XOOPS 2.6 Internationalization/Local support
  • 2013/1/23 4:11

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


well done Trabis. You have a very catchy eye.
Honestly we didnt have any major issue with the old definitions in persian as a RTL language.
I mean gender or plural words or even case sensivity are important for english or latin users but in persian they are not important.

the colon is not important in persian too but it is better to be recognized as you proposed.
just about question mark i should confirm that we have a different question mark in persian (en:? fa:؟)

48
irmtfan
Re: XOOPS 2.6 Internationalization/Local support
  • 2013/1/25 5:04

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


@Trabis:
I review your updates. they are really fantastic.
Now all local needs are covered include isRtl and isMultiByte.

just 2 point:
1- will you add strtotime in the future?

2- a bug in your example pt_BR in xoops26/locale/pt_BR/locale.php
class XoopsLocale extends XoopsLocaleEn_US{


should be XoopsLocalePt_BR

49
trabis
Re: XOOPS 2.6 Internationalization/Local support
  • 2013/1/25 8:11

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:

irmtfan wrote:
@Trabis:
I review your updates. they are really fantastic.
Now all local needs are covered include isRtl and isMultiByte.

just 2 point:
1- will you add strtotime in the future?

2- a bug in your example pt_BR in xoops26/locale/pt_BR/locale.php
class XoopsLocale extends XoopsLocaleEn_US{


should be XoopsLocalePt_BR


I'm glad you like it!
It is an ongoing process, right now I'm just covering the legacy. You should expect other methods later on.

Login

Who's Online

247 user(s) are online (183 user(s) are browsing Support Forums)


Members: 0


Guests: 247


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Mar 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits