trans January 2018

trans@lists.fedoraproject.org

10 participants
12 discussions

Proposal: Fedora G11N Steering Committee
by Pravin Satpute 26 Jun '20

26 Jun '20

Hi All, I am sure, most of the people working with Fedora I18N, L10N from 5-6 year must be aware regarding Fedora L10N Steering Committee. [1] As far as i know this committee was active around 2009 and very effective. During Fedora G11N activity day discussions, we again felt there is need for some kind of official committee to drive Fedora Globalization activities. Fedora is growing faster with number of different domains and G11N also need to adapt those changes quickly to remain on the track. For this purpose and in line with [1], we were thinking of Fedora Globalization steering committee. I have created initial proposal for it. [2] Its open for feedback, please feel free to share other active members, discuss in your respective language groups. This is just initial proposal and i am sure, we can improve and make it more effective with active participation. Regards, Pravin Satpute 1. https://fedoraproject.org/wiki/L10N_Steering_Committee?rd=L10N/SteeringComm… 2. https://fedoraproject.org/wiki/Fedora_G11N_Steering_Committee_Proposal _______________________________________________ g11n mailing list g11n(a)lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/g11n@lists.fedoraproject.org

10 28

Zanata.org update - website design
by Alex Eng 28 Apr '18

28 Apr '18

Hi, We have updated the design and contents of our home page *http://zanata.org/ <http://zanata.org/>* for better user experience. Any feedback is welcome. -- ALEX ENG SENIOR SOFTWARE ENGINEER, team lead globalisation tooling, customer platform Red Hat Asia-Pacific Pty Ltd <https://www.redhat.com/> Brisbane, Australia aeng(a)redhat.com M: +61423353457 IM: aeng <https://red.ht/sig>

2 1

[Bug 1361757] New: Typo in the czech localization Anaconda installer
by Red Hat Bugzilla 17 Feb '18

17 Feb '18

https://bugzilla.redhat.com/show_bug.cgi?id=1361757 Bug ID: 1361757 Summary: Typo in the czech localization Anaconda installer Product: Fedora Localization Component: Other language Severity: low Assignee: dimitris(a)glezos.com Reporter: mschorm(a)centrum.cz QA Contact: aalam(a)redhat.com CC: dimitris(a)glezos.com, piotrdrag(a)gmail.com, trans(a)lists.fedoraproject.org Description of problem: Typo in the czech localization Anaconda installer Version-Release number of selected component (if applicable): Fedora 24 x86_64 Downloaded workstation version from website https://getfedora.org/ How reproducible: Start czech installer any time and go to disk management. Select manual partitioning. You should be now on this screen: https://docs.fedoraproject.org/en-US/Fedora/24/html/Installation_Guide/imag… Actual results: Title "SVazek" Expected results: Title "Svazek" -- You are receiving this mail because: You are on the CC list for the bug.

2 1

Meeting regarding T-shirts for contributors with 500+ words translations in 2016
by pravin.d.s＠gmail.com 07 Feb '18

07 Feb '18

Hi All, We are going to have a short meeting on #fedora-g11n in 15min. Agenda is only T-shirt for contributors who contributed over 500 words in 2016. [1] We are almost in last stage of it, if anyone available feel free to jump in. Apologies for short notice, Thanks, Pravin 1. https://pagure.io/Fedora-Council/tickets/issue/69#comment-42173

11 23

New subscriber confirming email been rejected by the trans list
by Tiansworld 28 Jan '18

28 Jan '18

Hi all, Recently a new member from Simplified Chinese team tried to subscribe the translation mailing list. He made the subscription from here[1], and received the confirm email. Then he tried to reply the confirming email to the list with the topic "confirm 859bfffcba8af7e54ab83d1f64bbf3e58ec67f8a", but his reply was rejected by the list. So now he can't subscribe to this list by now. It seems that his address is blocked. Could the list moderator take some actions to handle this? This message is Cced to him and the trans-owner, please consider to remove the addresses when you reply. Thanks. [1] https://lists.fedoraproject.org/admin/lists/trans.lists.fedoraproject.org -- Regards, Tiansworld Fedora Project Contributor

4 4

Self-Introduction: Viktar Siarheichyk, Belarusian
by Viktar Siarheichyk 25 Jan '18

25 Jan '18

Name: Viktar Siarheichyk Location: Minsk, Belarus Login: veq Language: Belarusian Profession: A computer programmer. About: I use various linux distributions (mainly Debian) since 2001 both at work and at home. I worked on localization of the Debian installer and now wish to contribute to Belarusian translations of Anaconda. GPG KEYID and fingerprint: 25AA0BE5 E9EE 8133 AAAC 7529 58CB DB70 E7B6 46D7 25AA 0BE5

2 1

Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)
by Rafal Luzynski 24 Jan '18

24 Jan '18

24.01.2018 10:08 nicolas.mailhot(a)laposte.net wrote: > > > Hi Rafal > > > Does that mean it is finally possible for a user to set its default > date format to ISO 8601 without switching its language to Danish English? > [...] No, this was not a part of my work. I was working only on how the month names are spelled in different languages. I was not even aware that the problem of ISO 8601 date exists. Does it solve your problem if you set LC_TIME environment variable to en_DK or some other language? It would allow you to keep the rest of the system in your default language. Recently I have suggested to introduce en_EU instead of en_DK, this could save some people from being confused and ask "what is that Danish English and why should I use it". But that's a different story. Regards, Rafal

1 0

Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)
by Rafal Luzynski 24 Jan '18

24 Jan '18

24.01.2018 07:10 Florian Weimer <fweimer(a)redhat.com> wrote: > > On 01/22/2018 11:58 PM, Rafal Luzynski wrote: > > I'd like to notify you that today I've finished my works on date > > formatting in glibc, that means upstream. These changes are already > > arriving to Fedora Rawhide (they should be there tomorrow) and will > > be part of Fedora 28. They will be included in glibc 2.27 (to be > > released on February 1), or in pre-release upstream version > > 2.26.9000-1145 (in Fedora Rawhide: 2.26.9000-48). BTW, thank you Florian for delivering it to Rawhide so quickly. > Note that this is an ongoing effort. That's true, the change is visible only in languages where the locale data have actually changed. That's the reason why I'm asking the language communities for their opinion before we apply the change. So far only Polish language has been updated and there is some interest from Belarisuan and Russian communities but no final approval yet. > Some Romance languages will > eventually use this to correct the incorrect spelling of “de April” into > “d'April”. Once this happens, it will be necessary to change > translation strings for these languages from “de %B” to “%B”, otherwise, > the result will “de d'April”. That's true. So far I have identified three languages where the change will look like this: Asturian, Catalan, and Walloon. > (Yes, the meaning of %B changed in a backwards-incompatible way, and > glibc upstream deliberately implemented it this way.) That's true. But another argument is that it has never been specified whether %B is standalone or in-full-date-context. Probably because there was no such need in Germanic languages. It seems that translators have always treated this as a standalone version, probably except the Lithuanian community. Regards, Rafal

1 0

Fwd: User "veq" request to join [be] language team
by Alex Eng 24 Jan '18

24 Jan '18

FYI ---------- Forwarded message ---------- From: Zanata <no-reply(a)zanata.org> Date: Mon, Jan 22, 2018 at 9:51 PM Subject: User "veq" request to join [be] language team To: Dear Language Team Coordinator, Zanata user "Viktar Siarheichyk" with id "veq" is requesting to join the be (беларуская) language team Roles requested: - Translator veq has included the following message with this request: ------------------------------ I take part in translation of debian installer to Belarusian and would like to contribute to translating anaconda to Belarusian as well. ------------------------------ You can click the link below to go directly to the be language request page to process the request. Please reply to Viktar Siarheichyk at v(a)eq.by when you have finished processing this request. https://fedora.zanata.org/language/view/be/requests ------------------------------ You are receiving this mail because: There is no coordinator for language "be (Belarusian)" You are an administrator in the system configuration This message generated by Zanata running at: https://fedora.zanata.org _______________________________________________ trans-zanata-admin mailing list -- trans-zanata-admin@lists. fedoraproject.org To unsubscribe send an email to trans-zanata-admin-leave@ lists.fedoraproject.org -- ALEX ENG ASSOCIATE MANAGER globalization TOOLING, CUSTOMER PLATFORM Red Hat Inc <https://www.redhat.com/> 193 North Quay, Brisbane City QLD 4000 alex.eng(a)redhat.com <aeng(a)redhat.com> M: 0423353457 IM: aeng <https://red.ht/sig>

3 2

[HEADS UP] Changes in date formatting (strftime, nl_langinfo)
by Rafal Luzynski 22 Jan '18

22 Jan '18

I'd like to notify you that today I've finished my works on date formatting in glibc, that means upstream. These changes are already arriving to Fedora Rawhide (they should be there tomorrow) and will be part of Fedora 28. They will be included in glibc 2.27 (to be released on February 1), or in pre-release upstream version 2.26.9000-1145 (in Fedora Rawhide: 2.26.9000-48). What has been changed: * strftime() family (including stftime_l(), wcstime(), wcstime_l(), strptime() etc.): there are new format specifiers: %OB, %Ob, %Oh. It has been specified that the currently existing format specifiers: %B, %b, and %h generate the month names (%B--full month names, %b and %h--abbreviated month names) in a grammatical form required when the month is used as a part of a complete date (that means: together with the day number) while the new format specifiers with %O (note: this is O letter, the uppercase o, not the zero digit, 0) will generate the month names in a grammatical form required when the month is named by itself (without a day number, usually standalone). In most of the languages there is no difference between those two forms. However, there is a group of languages (about 20) where the correct form used in the full date is a genitive case while standalone months must be in a nominative case. * strptime(): just accepts the new format specifiers: %OB, %Ob, and %Oh; each of them recognizes any form of the month name. * nl_langinfo() family (including nl_langinfo_l()): there are new constants supported: ALTMON_1, ALTMON_2, … ALTMON_12, and also (kinda undocumented): _NL_WALTMON_1, _NL_WALTMON_2, …, _NL_WALTMON_12; _NL_ABALTMON_1, _NL_ABALTMON_2, …, _NL_ABALTMON_12; _NL_WABALTMON_1, _NL_WABALTMON_2, …, _NL_WABALTMON_12. These new constants generate the same month names as strftime() with %OB, %Ob, and %Oh format specifiers (month names standalone, which means a nominative case in some languages). The old constants MON_1, MON_2, …, MON_12, ABMON_1, ABMON_2, …, ABMON_12 generate the same month names as strftime() with %B, %b, and %h format specifiers--nothing new, it has been the same since forever. But from now these constants will generate the month names in a form used when the month name is a part of a complete date. That means they are unsuitable to generate the list of months standalone. What needs to be changed: * In Fedora: literally, nothing. The changes belong to upstreams and I'm writing here in hope that some upstream developers are here as well or you can forward the message to them. But of course upstream software eventually lands in Fedora (as well as in other distros). You may add "Requires: glibc >= 2.27" to the packages which rely on this new feature, that means if their upstreams required any changes in nl_langinfo() or strftime() calls. * Translators: if you want this feature to be supported in your language please notify me ASAP. There will be no change in the languages for which the locale data in glibc are not changed. So far only Polish language has been updated. Here is the list of languages which probably need the update (the list may be incomplete): Armenian, Asturian, Belarusian, Catalan, Croatian, Farsi, Greek, Kashubian, Lithuanian, Ossetian, Russian, Scottish Gaelic, Silesian, Sorbian (Upper and Lower), Ukrainian, Walloon. These languages probably do not need the change but should put their attention: Bosnian, Czech, Finnish, Serbian, Slovak. * Applications using nl_langinfo() to display months: well, you shouldn't use this function. This is a low-level function useful to implement strftime(). But if you really want to you can but you should stop using MON_* (and ABMON_*) and switch to ALTMON_* (and _NL_ABALTMON_*) instead. You should detect whether it is supported at compile time or at runtime. Well, it's tricky, isn't it? Therefore it's better to use strftime(). * Applications using strftime() to format dates: if you display a full date, including both the day number and the month name, that is when the format specifier is "%d %b %Y" or "%B %e %Y" or anything looking like that--no change is required. The only case is when you display the month name standalone, whether it's full ("%B") or abbreviated ("%b", "%h"), even when the year number is included ("%B %Y"). This should be changed to "%OB" and "%Ob". * Other libraries than glibc which wrap or reimplement the same API (like glib2 or gnulib): should enable this or apply the changes to their implementation. By "enable" I mean "define the new constants and do not raise an error when you see them or when you see the %O[Bbh] format specifiers in strftime()". * Other programming languages: the same as above, that means: if your language just calls nl_langinfo() and strftime() then make sure it calls it properly, defines the new constants and does not raise errors, or if it implements the same feature then the changes must be applied to your implementation. * Testers: make sure the dates are displayed correctly, especially in the calendars. You have to understand at least one of the languages which I have mentioned above, though. I guess this may lead to lots of questions and doubts. I have answered many of them so far but I understand that my impact is low so not many people heard the answers. Feel free to ask here or better let's discuss this during DevConf.cz. Regards, Rafal Links: https://sourceware.org/bugzilla/show_bug.cgi?id=10871 http://austingroupbugs.net/view.php?id=258 https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD https://rluzynski.fedorapeople.org/slides/2017-01-27-DevConf.cz/GenitiveMon…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

trans January 2018