View Issue Details

WikiRelated ChangesetsJump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0014099mantisbtlocalizationpublic2012-03-26 15:142017-02-14 17:23
Reporteratrol Assigned Todregad  
PrioritynormalSeverityblockReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.3.0dev 
Target Version1.3.0-beta.1 
Summary0014099: Implement new message format for master branch at translatewiki
Description

Commit [1] introduced a new message format and converted all language files.
The conversion was wrong for the error messages of the non english languages.
This should be fixed if the message files are generated from translatewiki.
At the moment you get English error messages despite of other language settings.

1) Synchronize messages in translatewiki (new / removed messages in master)
2) Implement the new output format in translatewiki

[1] https://github.com/mantisbt/mantisbt/commit/cad0ad10f4101da0c2947acfb75a1fc69b471cac#lang/strings_english.txt

TagsNo tags attached.

Relationships

related to 0022376 closedatrol Wrong documentation of string customization 
child of 0014088 closedvboctor Mantis 1.3.0 blocking issues 

Activities

dhx

dhx

2012-03-31 09:50

reporter   ~0031584

I've ditched this format in the 'next' branch and opted to use PHP's built-in gettext support. The Accept-Language header is used to correctly set the locale of the PHP instance so that first time/anonymous users can view the sign-up/login/etc pages in their native language.

Relevant commits:

https://github.com/mantisbt/mantisbt/commit/9f7894bfa3c15b809d924524061b80c5644b014f

https://github.com/mantisbt/mantisbt/commit/0816817885992463b648f122ac5657dd654db57d

https://github.com/mantisbt/mantisbt/commit/a50248866598592c210bcfe30c54cc08d69e6c47

I've talked to Siebrand (who co-runs the Translatewiki project) and he has advised that gettext is already implemented via another project that Translatewiki supports. gettext can be misused and we can't just dump work on TW. We need to ensure that all translations are:

  1. Context-aware.

  2. Linked to translation hints in the source code.

Furthermore, it's up to us to develop the TW plugin. This is easier to achieve now that another project on TW already uses gettext. Given that gettext is an "industry standard" which most translation tools have supported for well over a decade, a lot of work has already been completed for us.
vboctor

vboctor

2012-05-06 14:58

manager   ~0031771

@dhx, I'm not sure I understand the work involved here. However, if I'm understanding you correctly, here is what you are saying:

  1. We use format A in master-1.2.x, B in master, and C (gettext) in next.
  2. Format B will break compatibility with existing custom_strings_inc.php - based on how the code looks.
  3. Translate wiki supports format A and C, but not B. Hence, we can't get translation updates till translatewiki suppors B. Such support will have to be implemented by us.

If that is correct, then I wonder if we should go with:

  1. Kill format B, and move back to A for master.
  2. Kill format B, and move forward to C for master.
  3. Stick with format B, and implement support in translate wiki.

My preference is option 1.

We should really avoid having half backed feature that act as blockers for future releases. Changing the localization format should include a story for integration with translatewiki, otherwise, it is not ready for checkin.

In any case, are you working on this? I would really like to get 1.3.0rc1 out soon.
vboctor

vboctor

2012-06-01 03:14

manager   ~0031939

Pinging @dhx
grangeway

grangeway

2013-04-07 13:41

reporter   ~0036536

Atrol,

This format was added for performance [it's a lot quicker then the current setup, whilst also having the side benefit of having fewer global variables IIRC].

However, I've moved to trying to fix up the rest of dhx's gettext support - personally, I quite liked the new format in this commit, however the general consensus was to move to gettext when discussing was to move to gettext, as it's more of a standard. Therefore it would seem sensible to focus on whats needed around gettext then to improve this.

Paul
atrol

atrol

2013-04-27 16:38

developer   ~0036695

Reopened,
can be set to resolved again if 1.3.x will be based on branch master-1.2.x or master will be set back to the old message format.
dregad

dregad

2013-10-12 04:01

developer   ~0038246

This was resolved by reverting the language format back to the legacy 1.2.x style

Related Changesets

MantisBT: master 4728ff7c

2013-06-12 00:05

Damien Regad


Details Diff		 Fix 0014099: reverting to old language strings format Affected Issues
0014099
mod - config_defaults_inc.php Diff File
mod - docbook/Admin_Guide/en-US/Configuration.xml Diff File
mod - docbook/Admin_Guide/en-US/Customizing.xml Diff File
mod - docbook/Admin_Guide/en-US/Installation.xml Diff File
mod - lang/strings_afrikaans.txt Diff File
mod - lang/strings_amharic.txt Diff File
mod - lang/strings_arabic.txt Diff File
mod - lang/strings_arabicegyptianspoken.txt Diff File
mod - lang/strings_breton.txt Diff File
mod - lang/strings_bulgarian.txt Diff File
mod - lang/strings_catalan.txt Diff File
mod - lang/strings_chinese_simplified.txt Diff File
mod - lang/strings_chinese_traditional.txt Diff File
mod - lang/strings_croatian.txt Diff File
mod - lang/strings_czech.txt Diff File
mod - lang/strings_danish.txt Diff File
mod - lang/strings_dutch.txt Diff File
mod - lang/strings_english.txt Diff File
mod - lang/strings_estonian.txt Diff File
mod - lang/strings_finnish.txt Diff File
mod - lang/strings_french.txt Diff File
mod - lang/strings_galician.txt Diff File
mod - lang/strings_german.txt Diff File
mod - lang/strings_greek.txt Diff File
mod - lang/strings_hebrew.txt Diff File
mod - lang/strings_hungarian.txt Diff File
mod - lang/strings_icelandic.txt Diff File
mod - lang/strings_italian.txt Diff File
mod - lang/strings_japanese.txt Diff File
mod - lang/strings_korean.txt Diff File
mod - lang/strings_latvian.txt Diff File
mod - lang/strings_lithuanian.txt Diff File
mod - lang/strings_macedonian.txt Diff File
mod - lang/strings_norwegian_bokmal.txt Diff File
mod - lang/strings_norwegian_nynorsk.txt Diff File
mod - lang/strings_occitan.txt Diff File
mod - lang/strings_polish.txt Diff File
mod - lang/strings_portuguese_brazil.txt Diff File
mod - lang/strings_portuguese_standard.txt Diff File
mod - lang/strings_qqq.txt Diff File
mod - lang/strings_ripoarisch.txt Diff File
mod - lang/strings_romanian.txt Diff File
mod - lang/strings_russian.txt Diff File
mod - lang/strings_serbian.txt Diff File
mod - lang/strings_slovak.txt Diff File
mod - lang/strings_slovene.txt Diff File
mod - lang/strings_spanish.txt Diff File
mod - lang/strings_swedish.txt Diff File
mod - lang/strings_swissgerman.txt Diff File
mod - lang/strings_tagalog.txt Diff File
mod - lang/strings_turkish.txt Diff File
mod - lang/strings_ukrainian.txt Diff File
mod - lang/strings_urdu.txt Diff File
mod - lang/strings_volapuk.txt Diff File

MantisBT: master 6f267af2

2013-06-12 00:54

Damien Regad


Details Diff		 Fix error_string() following revert to old string format

Did not realize during testing of issue 0014099 that the error api had
been modified as well... reverting that change too.		 Affected Issues
0014099
mod - core/error_api.php Diff File

MantisBT: master 71d31deb

2013-10-11 09:23

dregad


Details Diff		 Revert language api changes for array message format

Cherry-pick of d679a60b136c0e2522c40c10bc436c9b5f5c47de, excluding
changes to language files.

Issue 0014099		 Affected Issues
0014099
mod - core/lang_api.php Diff File