Ticket #519 (closed enhancement: invalid)

Opened 7 years ago

Last modified 3 years ago

Language packs

Reported by: BrianKoontz Owned by: unassigned
Priority: normal Milestone: 1.3.1
Component: localization Version: trunk
Severity: normal Keywords: l10n i18n
Cc:

Description (last modified by NilsLindenberg) (diff)

Since we currently have no way for contributors to submit language pack translations of en.inc.php, I've created this ticket so contributors can attach their translations (if there is no special ticket, see list below). These can then be checked into the repo by one of the developers.

Existing language coordination tickets

  • #925 English (en.inc.php)
  • #684 German (de.inc.php)
  • #685 Italian (it.inc.php)
  • #686 French (fr.inc.php)
  • #687 Spanish (es.inc.php)
  • #698 Dutch (nl.inc.php)
  • #731 Polish (pl.inc.php)
  • #793 Vietnamese (vn.inc.php)
  • #920 Romanian (ro.inc.php)

Related tickets

  • #340 Work on Internationalization

Change History

  Changed 7 years ago by DarTar

  • keywords l10n i18n added
  • description modified (diff)

Three question to consider:

  • we should first normalize the existing constant names and agree on a scheme to be used in the future;
  • we should decide what to do with the installer, that currently adopts a totally different approach to l10n;
  • we should decide how to handle l10n strings for user contributed actions.

  Changed 7 years ago by DarTar

Also, default encoding should probably be set to UTF-8.

  Changed 7 years ago by JavaWoman

  • description modified (diff)

  Changed 7 years ago by NilsLindenberg

  • description modified (diff)
  • milestone changed from 2.0 to 1.1.7

  Changed 7 years ago by KrzysztofTrybowski

Polish translation is a work in progress. Default pages are translated, UI not yet. Either default encoding needs to be changes to UTF-8 or each language pack should set its own charset. I vote for UTF-8, since it's more universal and causes less problems in future.

How to deal with user contributed actions? Proposal to consider is to use a system similar to Debian's xxxx.d config directories. It works so that each file in such folder is processed. This way anyone could create a language file for his action and place it as /lang/pl/mostvisited.inc.php (for example).

Translations might be included in general lang files too. I do it this way with TRBCounter and TRBMostVisited.

Should I create a ticket for Polish translation?

  Changed 7 years ago by DarTar

KrzysztofTrybowski, nice to hear you are working on the Polish translation. Assuming we will hear from all  past translators, we should be able to bundle with 1.1.7 at least the following packages:

DE - EN - ES - FR - IT - JP - NL - PL - ZH

UTF-8 is the natural candidate charsets for language strings although for default pages we should consider problems related to our current  system requirements that allow Wikka to be installed on DB with no native Unicode support. For languages with charsets other than ISO Latin 1 we'll also need to modify the way content is rendered in the browser ( here is a related discussion).

The question of how to distribute translations for user contributed packages is very important but beyond the scope of this ticket. Th best way to distribute translations will depend on the system and conventions we settle on for the publication of  user-contributed plugins. These tickets on plugin extensibility may also relevant to the issue of how to link code and translation files.

  Changed 7 years ago by DarTar

  • description modified (diff)

  Changed 7 years ago by NilsLindenberg

Yes, please open a ticket for Polish. I will place a link here, then

  Changed 6 years ago by DarTar

  • description modified (diff)

  Changed 6 years ago by DarTar

(In [964]) First draft of Dutch language pack (Credits: Michiel Holtkamp), default pages still to be added, todos marked in the file, refs #698 and #519

  Changed 6 years ago by KrzysztofTrybowski

#731 - ticket for Polish translation.

  Changed 6 years ago by KrzysztofTrybowski

Should we also translate WikiNames of pages? There could be two approaches here:

  • translate default pages' names (pros: straightforward; cons: sometimes we need to know what's the name of a page with certain functionality, so maybe a mean of tracking those pages is needed)
  • treat WikiNames just as handles, and istead widen the use of page titles (pros: page index is always in PageIndex, my pages in MyPages etc.; cons: needs changes throughout whole Wikka)

The second idea implies, that WikiName is displayed only if page title doesn't exist. Everywhere. Also it implies that pages created by installer should have a title set. And that creating a link in a form [[PageIndex]] should display page's TITLE not WikiName. Tough, ain't it?

  Changed 6 years ago by NilsLindenberg

  • description modified (diff)

  Changed 6 years ago by DotMG

  • description modified (diff)

Added link to #793, vietnamese language pack.

  Changed 6 years ago by DarTar

  • milestone changed from 1.2 to 1.3

Retargeting to 1.3. Code for this ticket may have already been committed to trunk, from which 1.3 will be branched. Consider backporting urgent issues to 1.2.X

  Changed 5 years ago by DarTar

  • description modified (diff)

adding Romanian

  Changed 5 years ago by NilsLindenberg

  • status changed from new to closed
  • resolution set to fixed
  • description modified (diff)

  Changed 5 years ago by DarTar

  • status changed from closed to reopened
  • resolution fixed deleted

  Changed 4 years ago by GeorgePetsagourakis

I would like to enforce the belief in gettext. It is the best way to do this and most of the hosts support it due to Wordpress :)

  Changed 4 years ago by BrianKoontz

Great idea, George...but that won't happen in 1.3. We should definitely look at this in 1.4 though.

  Changed 4 years ago by DotMG

(In [1685]) refs #519, #97 : language packs are dynamically checked upon install. the installer will give the ability to choose one from the language packs present as default lang.

  Changed 4 years ago by BrianKoontz

(In [1691]) Initial PL translations by KT. Refs #519, #731.

  Changed 4 years ago by DarTar

I am testing the PL package - looks great.

Two important things we need to sort out before releasing: - we need to discuss a way of translating menulets, as they now show up in English - default page names should also be translated (especially now that we support unicode in page names). My feeling is that we should store default pages in the DB with their English name and then have aliases defined in the lang files to load the corresponding pages.

  Changed 4 years ago by BrianKoontz

The alternative to storing the default page tags in the DB is to simply read in anything that is in the default directory, taking the filename as the page tag.

I really don't see a need to hardcode these in the installer as they are now...

  Changed 4 years ago by DarTar

well yes, but we would not be able to map lang-lang equivalents, e.g. know how the FormattingRules page is called in Swahili. Two problems: (1) what if the Swahili translator abandons us and we need to know which page is which. (2) being able to represent the correspondence of page names across languages would enable something like the functionality I describe in #996

follow-up: ↓ 27   Changed 4 years ago by KrzysztofTrybowski

If Swahili translator abandons us, then we'll have general problem with this translation, far wider than just inability to say which is which. BTW — this won't be that hard, you can find out by actions, categories, content length, specific parts, etc.

Representing the correspondence of page names across laguages is a different — and still open — issue. Actually these are two sepearate things: to have localized, translated wiki, and to have a multilingual wiki.

How is it done in MediaWiki? I think (no sure though!) that there are just links on a page, leading to the same page in different language. So I guess there isn't any centralized place where all different language versions are linked. Is there?

in reply to: ↑ 26   Changed 4 years ago by DarTar

Replying to KrzysztofTrybowski:

How is it done in MediaWiki? I think (no sure though!) that there are just links on a page, leading to the same page in different language. So I guess there isn't any centralized place where all different language versions are linked. Is there?

no, MW definitely has aliases, if you try to open:

 http://it.wikipedia.org/wiki/Utente:DarTar  http://it.wikipedia.org/wiki/User:DarTar

they both point to the same page

  Changed 4 years ago by BrianKoontz

(In [1696]) Removed the following defines from en.inc.php, as I do not believe they are used elsewhere in the source code. Refs #519.

ANONYMOUS_USER 0

BUTTON_NEW_COMMENT 0

BUTTON_REPLY_COMMENT 0

BUTTON_RETURN_TO_NODE 0

BUTTON_SEND_PW_LABEL 0

BUTTON_SHOW_DIFFERENCES 0

CHANGE_BUTTON_LABEL 0

CHANGE_PASSWORD_HEADING 0

COMMENT_ACL_LABEL 0

COMMENT_AUTHOR_DIVIDER 0 CURRENT_PASSWORD_LABEL 0

DIFF_ADDITIONS 0 DIFF_DELETIONS 0

DIFF_LINK_TITLE 0

DISPLAY_COMMENTS_THREADED 0

EDITED_BY 0

ERROR_ACL_READ_INFO 0

ERROR_DURING_FILE_UPLOAD 0

ERROR_EMPTY_USER 0

ERROR_FILE_EXISTS 0

ERROR_MAX_FILESIZE_EXCEEDED 0 ERROR_NON_EXISTENT_USERNAME 0

ERROR_NOT_EXISTING_PAGE 0

ERROR_NO_FILE_UPLOADED 0

ERROR_NO_FILE_UPLOADS 0

ERROR_NO_READ_ACCESS 0

ERROR_OLD_PASSWORD_WRONG 0

ERROR_OVERWRITE_ALERT 0 ERROR_USERNAME_EXISTS 0

ERROR_WRONG_HASH 0

FREEMIND_PROJECT_URL 0

INPUT_BUTTON_CANCEL 0

INPUT_SUBMIT_PREVIEW 0

INPUT_SUBMIT_REEDIT 0

INPUT_SUBMIT_STORE 0

LABEL_EDIT_NOTE 0

LABEL_ERROR 0

LASTEDIT_MESSAGE 0

LOGIN_BUTTON_LABEL 0

LOGIN_HEADING 0

LOGIN_REGISTER_HEADING 0

LOGOUT_BUTTON_LABEL 0

MAX_DATETIME 0 MIN_DATETIME 0

NEW_USER_REGISTER_LABEL 0

NOT_AVAILABLE 0 NOT_INSTALLED 0

PASSWORD_CHANGED 0

PASSWORD_REMINDER_LABEL 0

PREVIEW_HEADER 0

QUICK_LINKS 0

QUICK_LINKS_HEADING 0

RAW_LINK_DESC 0

REGISTERED_USER_LOGIN_LABEL 0

REGISTER_BUTTON_LABEL 0

REGISTRATION_SUCCEEDED 0

RETRIEVE_PASSWORD_HEADING 0 RETRIEVE_PASSWORD_MESSAGE 0

REVERTLINK_TITLE 0

REVISION_NUMBER 0

RSS_RECENTCHANGES_VERSION 0

SEARCH_TIPS_TITLE 0

SIMPLE_DIFF 0

TITLE_REVISION_LINK 0

TODAY 0

UPDATE_SETTINGS_INPUT 0

USER_LOGGED_OUT 0

USER_SETTINGS_HEADING 0

USER_SETTINGS_STORED 0

WIKKA_NO_PAGES_FOUND_FOR 0

  Changed 4 years ago by DarTar

We should either change the milestone and description of this ticket to reflect the new gettext-based implementation or close it as obsolete.

  Changed 4 years ago by BrianKoontz

  • status changed from reopened to closed
  • resolution set to invalid

Let's close it as obsolete...I'll reference it in #1015 so we don't lose track of it. We will need a new ticket for the same purpose.

  Changed 3 years ago by BrianKoontz

  • milestone changed from 1.3 to 1.3.1

Changed milestone to 1.3.1

Note: See TracTickets for help on using tickets.