Skip to content
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

Open
nibra opened this issue Jun 4, 2016 · 4 comments
Open

Localisation Library #106

nibra opened this issue Jun 4, 2016 · 4 comments
Milestone

Comments

@nibra
Copy link
Member

nibra commented Jun 4, 2016

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.

@nibra nibra added this to the X.0 milestone Jun 4, 2016
@Biromain
Copy link

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"

@Fedik
Copy link
Contributor

Fedik commented Sep 21, 2016

maybe use Gettext ?
just _("Article") instead of COM_CONTENT_ARTICLE

@Biromain
Copy link

Article is just an example. We can have more complicated situations.

AFAIK

  • Gettext use compiled file for translation and cache this on HTTP Server (Restart to clear).
  • Don't think so easy to override language at runtime.
  • We are directly on an extension without any ways to modify behaviors.
  • Need ASCII key/reference.

Symfony use symfony/translation.

  • ArrayLoader - to load catalogs from PHP arrays.
  • CsvFileLoader - to load catalogs from CSV files.
  • IniFileLoader - to load catalogs from ini files.
  • MoFileLoader - to load catalogs from gettext files.
  • PhpFileLoader - to load catalogs from PHP files.
  • PoFileLoader - to load catalogs from gettext files.
  • QtFileLoader - to load catalogs from QT XML files.
  • XliffFileLoader - to load catalogs from Xliff files.
  • JsonFileLoader - to load catalogs from JSON files.
  • YamlFileLoader - to load catalogs from Yaml files (requires the Yaml component).

We need to search why not just gettext only.

@nibra
Copy link
Member Author

nibra commented Sep 27, 2016

Added some requirements to the intro.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants