Thanks for the patch.
Unfortunately it introduces some problems, test compiling it gave:

Error: Duplicated default for usage="DATE" type="medium": formatindex="34".
Error: Duplicated default for usage="DATE" type="medium": formatindex="35".
Error: TimeSeparator not present in FormatCode formatindex="44".
Error: Time100SecSeparator not present in FormatCode formatindex="44".
Error: Time100SecSeparator+00 not present in FormatCode formatindex="44".
Warning: formatindex="4","44","45" are the only FormatCode elements checked for separator usage, there may be others that have errors.
Error: TimeSeparator not present in FormatCode formatindex="45".
Error: Time100SecSeparator+00 not present in FormatCode formatindex="45".
Warning: formatindex="4","44","45" are the only FormatCode elements checked for separator usage, there may be others that have errors.
Error: FormatElement formatindex="48" reserved for internal ``BOOLEAN''.
Error: FormatElement formatindex="49" reserved for internal ``@'' (TEXT).
Generated date acceptance pattern: 'Y/M/D' from 'YYYY.M.D' (formatindex="21" and defined DateSeparator '/')
Generated  2nd acceptance pattern: 'Y.M.D' from 'YYYY.M.D' (formatindex="21")
Error: Duplicated DateAcceptancePattern: Y.M.D

The mere numbering (reserved formatindex values) problems can be sorted out by properly following the prerequisites lined out in http://cgit.freedesktop.org/libreoffice/core/tree/i18npool/source/localedata/data/locale.dtd

That may already also solve the "TimeSeparator not present" errors if those formats get the correct index again.

As for the 'Duplicated default for usage="DATE" type="medium"' error, there can be only one default format for each usage and type combination.

formatindex="21" was changed from YYYY/M/D to YYYY.M.D hence the error about duplicated date acceptance pattern as Y.M.D is also explicitly listed as a DateAcceptancePattern element, so this could be solved by removing that extra definition. However, what concerns me is that almost all formats use '/' separator, and this edit format now uses '.' separator. That may be confusing for users if the date is displayed with '/' and when editing it changes to '.'. Of course I don't know about Taiwan conventions, so this change may be desired.

formatindex="18" was changed from YY/M/D to M/D/YY so changes order from YMD to MDY while all other formats have YMD order. Is that on purpose? Given that the year is displayed only with 2 digits it may be quite confusing.

For the new (NN) please put the parentheses in quotes as they are literal characters to be displayed, so "("NN")"
I also suggest to use the more common DDD for abbreviated day of week instead of NN, so "("DDD")"

I would be delighted if you could submit a corrected patch :-)

Thanks
  Eike

Sorry, I have not learned to build libreoffice yet. :P

But thanks, I will check the errors and submit it again! :)

No problem, usually localizers don't build and I correct syntactical problems when encountered, it's just that there are also some changes I wasn't sure of. If you get stuck just tell me and I'll do what's needed.

I found out that I did not properly follow the prerequisites, so I will redo the adaptation again to meet the rules. :P

Thanks for telling me the information, Eike Rathke! :)

I have a few questions:
1. Is it possible to add Y/M/D as a acceptance pattern?
2. It is hard to set date corresponding to DATE_SYS_XXYYZZ or DATE_DIN_XXYYZZ in Chinese. How should I do this? Just using the format we commonly use regardless of DDMMYYYY, DMMMYYY, etc.?
3. There are duplicated date format defined in NumberFormatIndex.idl. formatindex 18 is the same as 20 (DATE_SYSTEM_SHORT and DATE_SYS_DDMMYY,08.10.97), and formatindex 19 is the same as 29 (DATE_SYSTEM_LONG and DATE_SYS_NNDMMMMYYYY, Wednesday, 8. October 1997). So should the localized date formant follow this rule?
4. Chinese using traditional numbering instead of Arabic numerals in formal date writings. For example, 一 for 1, 二 for 2，三 for 3, 四 for 4, 五 for 5... etc. So 5/3 is 五月三日. Is is possible to use this kind of writing in the future?

(In reply to comment #5)
> I have a few questions:
> 1. Is it possible to add Y/M/D as a acceptance pattern?

As the date separator is '/' and the formatindex="21" edit format is
YYYY.MM.DD the pattern Y/M/D is already automatically generated.
Additionally the Y.M.D pattern is generated, causing the duplicated
pattern error because that pattern was also manually defined. Removing
the manual definition will solve that.


> 2. It is hard to set date corresponding to DATE_SYS_XXYYZZ or DATE_DIN_XXYYZZ
> in Chinese. How should I do this? Just using the format we commonly use
> regardless of DDMMYYYY, DMMMYYY, etc.?

Hard to say. Best to stick with a definition close to the original
meaning but use locale preferences. It may help to know that for the
format codes index<50 when a document uses Standard system locale (not
fixed to a specific locale) in number formats, switching the locale
under Tools->Options->Languages->LanguageSettings->Locale displays the
dates formatted with the format code of the same index in the new
locale.


> 3. There are duplicated date format defined in NumberFormatIndex.idl.
> formatindex 18 is the same as 20 (DATE_SYSTEM_SHORT and
> DATE_SYS_DDMMYY,08.10.97), and formatindex 19 is the same as 29
> (DATE_SYSTEM_LONG and DATE_SYS_NNDMMMMYYYY, Wednesday, 8. October 1997). So
> should the localized date formant follow this rule?

Probably yes. Some locales followed an approach that they define
slightly different formats so there are no duplicated formats in the
list displayed, but technically that is not necessary.

Originally the duplicated formats may had different separators and YMD
order (with ..._SYS_... obtained from Windows' Regional Settings) or be
entirely different (again with ..._SYSTEM_... entire definition obtained
from settings). This differentiation got lost when moving to an i18n
framework but formats needed to be preserved for backward conmpatibility
with older binary documents.

At some point we'll have to rework these things, it's currently a bit
messy.


> 4. Chinese using traditional numbering instead of Arabic numerals in formal
> date writings. For example, 一 for 1, 二 for 2，三 for 3, 四 for 4, 五 for 5... etc.
> So 5/3 is 五月三日. Is is possible to use this kind of writing in the future?

You can already :)  Use a [NatNum#] modifier to display transliterated
numbers. For example
[NatNum1]YYYY/MM/DD
today displays  二〇一二/五/八

Actually for Chinese there are different NatNum modes, a brief
description is available in
http://cgit.freedesktop.org/libreoffice/core/tree/offapi/com/sun/star/i18n/NativeNumberMode.idl

The calendar display modes used is a bit complicated, in the example for
NatNum1 CAL: 1/7/7  it should be
Year displayed with NatNum1, Chinese lower case characters.
Month displayed with NatNum7, Chinese short lower case text.
Day displayed with NatNum7, Chinese short lower case text.

Created attachment 61873 [details]
proposed new zh_TW.xml

This is the new zh_TW.xml file I edited.

I have rewritten the file. The chages listed below:

1. DATE_SYSTEM_SHORT and DATE_SYSTEM_LONG are referred to Windows ones, but added NNNN for LONG format
2. try to stick with a definition close to the original meaning but use locale preferences
3. YY is not widely used in Chinese (Taiwan), and easily confused with EE. I changed YY into EE instead
4. MMM (DefaultAbbrvName) was the same with MMMM (<DefaultFullName). MMM is slightly changed to separate MMM and MMMM usage, eg. 1月 vs 一月. This is commonly used in other localization work of free software, eg. "cal".
5. MMMM uses native numbering. Added [NatNum1] as prefix to let all the date format be consistant. Plus, native numbering is quite important in official documentation usage.
6. use DDD instead of NN
7. YYYY"年"QQ is more commonly used than EE"年度"QQ, changed
8. DATETIME_SYSTEM_SHORT_HHMM is changed to like DATE_SYSTEM_SHORT
9. DATETIME_SYS_DDMMYYYY_HHMMSS is changed to fit YMD order used in Chinese (Taiwan)
10. CurrencyName changed from "New Taiwan Dollar" into localized "新臺幣"
11. added some MinGuo (EE, GGEE, GGGEE) and YYYY formats which close to or missing in the definitions listed in NumberFormatxIndex; and M"."D added => formatindex 50-79

Eike, would you please help me check this new file? If there is some things I have to noted or have to be improved, please tell me! ;)

Perfect :-)  No warnings or errors, looks good from what I can tell.

Cheng-Chia Tseng committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b676fa6df5ba3ed08c685184f6843aeaffa3d94f

updated [zh-TW] locale data fdo#49274