Providing translations for default langauge

Permalink
Is there any way to provide translations for a site/package's default language? We are running multiple sites on 8.2 and have run into an issue where clients want strings in a package changed, but because their sites are in English these strings are essentially hard-coded.

There is no option to translate the site's default language through the 'Translate Site Interface' page. If an en_us .mo file is provided this does not get loaded. Based on my understanding of gettext this seems to be non-standard behaviour, however I'll happily be corrected as admittedly my experience is limited.

Is anyone aware of a workaround for this? I had a look but couldn't find any similar questions so maybe there's something obvious I'm missing or I'm not understanding the multilingual functionality correctly.

Thanks!

View Replies:
mlocati replied on at Permalink Reply
mlocati
You can add a PHP file with the strings that you want to customize.

For instance, if you want to customize the translations for "Ok" and "Cancel", write this PHP code:
<?php
t('Ok');
t('Cancel');


You have to save this file in a location parsed by the site strings extractor (seehttps://github.com/concrete5/concrete5/blob/8.2.1/concrete/src/Multi... ), for instance you could save it as
/application/elements/strings.php

Then, in the /dashboard/system/multilingual/translate_interface dashboard page, after hitting the "Reload Strings" button, you should be able to translate the strings.
attacker replied on at Permalink Reply 3 Attachments
Thanks for your response. My Issue is that there is no option to provide translations for the site's default language. This is the same across multiple sites. I have one site which for some reason is allowing me to provide translations for English, but these translations are ignored, despite an en_US .mo file being created.

I've attached screenshots of the translate site page.
attacker replied on at Permalink Reply
I've had a look in the source for the translate_interface page and it seems that Concrete explicitly doesn't support translating the site's default language.

in concrete/single_pages/dashboard/system/multilingual/translate_interface.php:
<?php
                                if ($pc->getLocale() == $defaultSourceLocale) {
                                    ?>
                                    <td></td>
                                    <?php
                                } else {
                                    ?><td><a href="<?php echo $this->action('translate_po', $pc->getCollectionID()); ?>" class="icon-link"><i class="fa fa-pencil"></i></a></td><?php
                                } ?>

Does anyone have an explanation for why this is? Am I misunderstanding the purpose of translations? I'm asking because there is need for us to change package strings between clients, so we can't change the identifiers passed to gettext via the t() function.
mlocati replied on at Permalink Reply
mlocati
I'm really curious about why you need to customize the en_US strings: could you give me an example?
attacker replied on at Permalink Reply
Mostly so we can customise strings in packages across sites without having to override anything.

If we have 15 sites running a package, and each requires customised strings (in elements, validation classes, etc.) we could override these files but then we'd have to manually update the overriding files any time the overridden file is updated.

If there is a better way of doing this I'd be open to suggestions.
mlocati replied on at Permalink Reply
mlocati
Now I understand what you meant with "default language": it's en_US.

You can enable loading .mo files for en_US by setting the concrete.misc.enable_translate_locale_base_locale configuration option to true

Via a console, this can be done with the c5:config CLI command:

concrete/bin/concrete5 c5:config set concrete.misc.enable_translate_locale_base_locale true
attacker replied on at Permalink Reply
This looks like exactly what I need! I'll try it out, thanks!