I have another question related to this: I wrote (or better: I'm writing) a package myself and wondered how to implement localization for this package.
I created a message.po/mo under in my package tree and on top of my views I switched to my mo-file and at the and I switched back to the default one. Does this somehow coincide with the concepts of the core developement?

This works so far, but there are still problems: how can I add translations to the core regarding my package, for example names and descriptions shown in the package list...

has c5 an interface for package localization?? I don't think normal users like to care for po files and conversion stuff etc.

I'm fond 2 position.
/concrete/libraries/block_view.php line 192


this $base is



other
/concrete/models/block_type.php line 456

this code for block install.

great! This is exactly what I thought of (that's the reason why I love C5: everything is like I expect it should be ;-) - but it's for blocks only. There is no equivalent for packages (the dashboard pages), is there?

Blocks are nice in that they're pretty encapsulated - but packages can have many different pieces, as you've seen. There's currently no way to localize an entire package, just blocks within that package.

thanks for your confirmation. This assures me of not having written bad and redundant code...

I was just going through setting up some base localization for blog.. I was setting up each block and slowly spreading everything everywhere and it was becoming a mess. I desperately wanted it to work like the core translation... One nice file.

Here's what I settled on...

I created a file in my packages libraries dir called mypackage_localization.php which contained:



With a little more work, I'm sure I could just pass my results on to t() instead of duplicating t's code... I wasn't yet sure how to handle the extra arguments for that.

Next, in my package controller I added:



Now everywhere in my code that I used t(), I just use mypackage_t(). This gives me centralized localization for my entire add-on while not running over concrete's localization.

I think it's rather elegant.

Another solution would be if concrete's core had a pkg_t() method build in where you could say something like:



Since my solution needs to work on any install, I went with this.

I still need to see if it will work on a fresh install of the block.

In the messages.po or in a new file placed under LC_MESSAGES?

As far as I understand the code that kino posted, you have to put it in a file called messsages.mo and put it in the block's folder under /languages/xx_XX/messages.mo.

/yourinstallationpath/blocks/blockname/languages/xx_XX/messages.mo

thanx, that makes it clear.

Thanks for releasing this :)
helped me a lot!

Annekeh,

I'm currently working on translation in the blog core. I have some po files I can send you for the various blocks if you'd like to contribute edits to them.

My next step is to work out translations for single pages and page types, which this thread will be very beneficial for.

As I go through this, some of the core code is changing to be more translation friendly.

Please feel free to communicate with me as I am one of the core blog devs.

Thanks,

jereme

Hi Jereme,

Yes, please sent me the po files. I was already busy with the translation of the blog and gallery. I will merge the files.

It will be the dutch translation.

I do have one question about the translation. In dutch we use an hyphen in plural. e.g. pages / pagina's. The hyphen ' sometimes messes up the javascript. Is there a way to avoid this.
I already tried to escape but in other places in the dashboard i see pagina\'s.

you need my email for the po files, or do you post them here?

Grtz, Anneke

Just for the record, I'm going to leave what I have in my mind for add-on internationalization.

I am not talking about immediate solution.

What I am suggesting is the long-term solution which requires a major system re-structure of concrete5. But I believe this is necessary for more multi-language support.

==============================
Current Stage (5.3.3.1)
==============================
- One language per site only
- Using gettext system
- No add-on support

==============================
Current Problem (5.3.3.1)
==============================
- Add-on is not internationalized
- concrete5 only accept one message (.mo) file only
- You cannot add and remove (.mo) file when install/uninstall add-on
- Marketplace is only in English
- We are only using t(), this may cause the conflict

==============================
My Suggestion for internationalization
==============================
Before I talk about marketplace, I would like to express my opinion only for add-on translation.

- Use gettext for core messages for speed
- Create additional XML system with its own assigned message wrapper (like Joomla system)

So the core system will stay the same.
We work on the messages.po file and compile it to .mo file.

But when it comes to add-on... for example, we ask developer to wrap all messages by its own original block ID.

For example, let's say there is word "message" in the add-on block. We will wrap the message by using btext_BLOCKUNIQUE_NAME().

And we can create an xml file with format
[Original string in php] = [translated text]

--------------------
e.g.) "Blog" block in php
--------------------
btext_blog('Message')
--------------------
e.g.) packages/languages/de_DE/blog.xml
--------------------
Message = Nachricht
Hello = Hello
--------------------


==============================
The reason behind
==============================

The add-on message could be .mo format as well. But I would like to ensure about unique ID for block text wrapper.

The main reason is to avoid the conflict of a same word in a different language.



For example,

When I was translating an extension of Joomla. This particular block was using the word "State" as status.

But the word "State" was also used as "Province/Region" in English.

So Joomla Japanese translation team already translated "State" to be "Region"

So the word "State" was reserved to be "Region/Province".

When I tried to use this particular add-ons, where it should say "Status" says "Region/Province" in Japanese which does not make sense.



So people may suggest to create a guideline. And it may be the waste of resources.

It will be easy if there is small number of add-ons.

However, if we start having thoughsand add-ons, it's virtually impossible to keep a certain guideline.

It's better to let add-on blocks to have its own text ID wrapper for unique meaning.

==============================
In short
==============================
- We use t('ORIGINAL MESSAGE') for core translation
- We use btext_BLOCKID('ORIGINAL MESSAGE') for add-on block translation

guys, you know that the current svn version has some new stuff about localization which would make it easier to build multi language blocks?

not checked out so far, tell us more, zend translate i guess?

yes, this allows two things:

1 dynamically change languages

mysite.com/?lang=de
which would set lang to de which would then make sure all blocks use the german gettext file

2. use multiple language files

allows a block/package to have its own translation file..

ok, hopefully it's coming soon. I've a client that now uses xt commerce instead of concrete5 ecommerce because it's not translated...

code is not finished.
was made for fun

description:
automatic string extraction
automatic translation into 52 languages
automatic gettext po to mo compilation
automatic language dependant redirection

^ it works, but have to put the pieces together..

cheers
Fernandos..

Fernandos, you know about the current Zend_Translate development which is going on?

I doubt that your code will make it into the core, it's a lot more complicated than the stuff based on Zend_Translate.

If you add some more features (geoip etc.), please make sure that it uses the core translation stuff and not some custom code which we have to merge into the code with every release.

hi Remo :)
you probably expect a bit too much from me, I'm not Andrew ^ :P .

And I'm not that familar with "Zend", so I'd to learn it first before writing a single line of code. I've just written a lil app that crawls the code for strings put's them in to po file, sends that to a machine translator, create another po file for every successfull translation and compiles them all et cetera.

purpose: make translating addons easier.

Well, I just want to make sure you don't waste your time.

What you describe isn't in the core, and might still be useful at some point. But accessing several gettext files is probably going to be better with zend and lets us do smarter translation stuff...

EDIT:
Well, I already did it ..
Was playing with ajax.

Well you're right doing this with Zend::Translate might be the best option.

Well, I found the subversion repository.
Probably no need for what I've done.

Then try that with C5.

"kino's quick localization" has been created.
If the same input and output gettext
Check the DB
If bilingual output, it
If not, DB registered
Management screen you can edit the table.
Someone who like to use?

1st.
install "kino's quick localization" package

2nd.
copy localization.php (in attached file) to
/libraries/

This program adds a few features later.
After that will be registered in the marketplace.