-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Localisation Library #106
Comments
I think i18n most not depend on file format. Like Symfony, we just need parser (xml, ini, yml, po, whatever), each ext devs can choose what he like and use key path format like layout in J3. $translator->trans('com.content.article'); <translation key="com_content_article" value="Article"> com: {
content: {
article: "Article"
}
} COM_CONTENT_ARTICLE="Article" |
maybe use Gettext ? |
Article is just an example. We can have more complicated situations. AFAIK
Symfony use symfony/translation.
We need to search why not just gettext only. |
Added some requirements to the intro. |
Library to localise strings
Requirements
Current language files MUST be re-usable.
A lot of efford has been put into translations into a vast number of languages. It does not make sense to discard that work.
Admin MUST be able to define a fallback, ideally a fallback cascade.
Example: If the current language is Swedish, use Danish for missing translations. If there's no Danish translation, too, use English instead.
Language definitions MUST be overrideable.
Wording and phrases are often changed to match the style of the site. Those changes must not be reverted on updates.
The call of the translation function SHOULD have a very small footprint.
A short notation is preferred. The
gettext
function_('foo')
is ideal in this regard. A construct like$languageManager->translate('foo')
is too obstrusive.The text was updated successfully, but these errors were encountered: