Please use the suggested format.
Thanks,
Saroj
On Jan 24, 2017 6:26 AM, "Philippe Verdy" <[email protected]
<mailto:[email protected]>> wrote:
Ok between a quantity number (provided it is a short integer) and
the following noun or unit (unconditional non-breaking before
abbreviated units such as "m" or "kg"), but between a mouth day
number and a month or a month and a year, there's no such
restriction and the space is perfectly breakable (there's no
quantity-unit relation between these numbers that are just
enumerated in order).
It is just suggested, in wide enough paragraphs, to avoid breaking
dates, but the same could also be said about peole names (first
name, last name) or toponyms: this is a styling refinement when
typesetting documents, but actually this only applies if you can
predeict the paragraph width and the unbreakable part is narrow
compared to the paragraph, and probably only implemented when
using justified paragraphs and other whitespaces can be expanded.
This "rule" on dates is then definitely not a rule but a matter of
preferences, and only applicable to typesetted documents, when you
know the fonts used, their sizes, the paragraph width, and the
kind of text justification made (or microjustifications, including
kerning and variable floatting) around complex non-recangular shapes.
If you have a table containing dates, non-breaking spaces will be
worse as it will force other columns to become narrower or to have
overlapping columns. long dates are perfectly breakable in that
case I can see lot of examples of printed books where long dates
in paragraphs are broken by linewraps because these are clearly
separate words in an enumeration (it does not matter if the day
number or year is spelled completely or written with digits, or if
there's a weekday name prepended or time appended). Only dates in
short format (dd/mm/yyyy) are unbreakable.
2017-01-24 1:11 GMT+01:00 Pols12 <[email protected]
<mailto:[email protected]>>:
According to w:fr:WP:TYPO
<https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_typographiques#NON_C.C3.89SURE_NOMBRE_NOM>,
we should use non-breakable spaces in French long format dates.
2017-01-23 19:36 GMT+01:00 Philippe Verdy <[email protected]
<mailto:[email protected]>>:
There'a absolutely no need of non-breaking spaces in
French dates ! The numeric format "dd/mm/yyyy" has no
space at all. The long format "dd monthname yyyy" uses
standard spaces for word separation (they are breakable).
And there's NEVER any space in the middel of the year.
However the French non-breaking spaces are need for
punctuations (before "!", "?", ":" or in the middle of «
guillemets » (standard French quotation marks) or in
numbers as group separators. These should ideally be
narrower than standard spaces (i.e. NNBSP U+203F rather
than NBSP U+00A0). But none of these occur in French dates.
2017-01-23 19:09 GMT+01:00 Pols12 <[email protected]
<mailto:[email protected]>>:
According to me, it’s a real improvement.
How can we edit or suggest an edit to the date format?
Indeed, we used to use non-breaking spaces in French
dates.
Pols12
2017-01-23 8:45 GMT+01:00 mathieu stumpf guntz
<[email protected]
<mailto:[email protected]>>:
Well, I don't have much knowledge about calendar
living practices beyond Greogorian calendar, sorry
if I misunderstood your problem. Does that also
apply to day names, or just month names?
Would you be kind enough to give me some concrete
examples of what you would like to obtain and what
are possible side effect you are concern about,
with some explanation and latin transcription (if
possible)?
I still believe adding other calendar support
might have some interest. But maybe it would be
more relevant to continue this aspect of the
discussion on the phabricator ticket
<https://phabricator.wikimedia.org/T155824>.
Le 20/01/2017 à 13:40, Haytham Abulela ALY a écrit :
Hi Mathieu,
My comment is not related to Assyrian or Aramaic.
The issue is that countries of the Levant and
Mesopotamia have applied the names of the
Assyrian/Aramaic calendar to the Gregorian
calendar in Arabic letters. This has become a
norm for decades. I think that all that needs to
be done in this regard is to update the list from
which the string of code suggested retrieves
values, and the string of code shall remain as is
without any changes necessary. My concern here
would be that this might affect values in cells
of tables, since the string of text will comprise
of two or three words. If this matter becomes a
nuisance, we may ignore it as the current state
of affairs is suitable for the majority of Arabic
speakers. I was trying to have an inclusive
approach instead of favouring one format over
another.
Regards,
On 20 January 2017 at 02:25, mathieu stumpf guntz
<[email protected]
<mailto:[email protected]>> wrote:
Saluton Haytham,
If you look at the documentation
<https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time>,
non-Gregorian formating is supported. Now
having a deeper look at it, it seems that
Assyrian calendar
<https://en.wikipedia.org/wiki/Assyrian_calendar>
is not yet in the set of supported calendars,
so a phabricator ticket should be filled here
I think, shouldn't it. I don't know what is
the the ISO 639-3 you would like to use
"/aii/" (Assyrian Neo-Aramaic) or /"arc/"
(Aramaic language), but in both case it seems
that localization is missing
<https://www.mediawiki.org/wiki/User:Psychoslave/asiria_kalendaro>
for already provided month names.
So for the sake of the example, let's say
there was a "xaF" formatting code which would
provide an Assyrian calendar full month name,
then as far as I understand, you would like
to use:
{{#time:xaF|$date1|aii||}}
({{#time:F|$date1|aii||}})
Thank you Johan for the feedback request. We
have here and there complaints when staff is
argued to not take enough into account
community advises, so it seems fair to also
emphasize actions when they are done with a
community feedback in the loop.
Le 19/01/2017 à 18:58, Haytham Aly a écrit :
Hi Johan,
This idea is brilliant.
My own concern for Arabic is that there are
two major ways for displaying Gregorian
month names; transliteration as well as the
Assyrian names. Usually transliterated names
suffice, but I prefer using both divided by
a slash. This is due to differences in
official use, since transliterated names are
used in Egypt, Sudan, Libya, Yemen, and Gulf
states; while Assyrian names are used in
Iraq, Syria, Lebanon, Jordan and Palestine.
Could this automation function render both
or just the common transliterated month
names? It would be a bonus to have both
displayed, though only transliterated month
names would suffice.
Regards,
Haytham Abulela Aly
Freelance Translator
Creative Translation
"Creative & Confident"
Certified member of the Society of Translators and
Interpreters of British Columbia (STIBC) (EN>AR)
Arab Professional Translators' Society member (#10850)
Certified member at Egyptian Translators Association
(EGYTA)
Registered at ProZ.com and LinkedIn.com
On 19/01/2017 8:31 AM, Johan Jönsson wrote:
Hi everyone,
TL;DR: Dates in items that are in the
newsletter every week could be in a format
that means you could get a 100% in the
translation memory and not have to change
the days and months every week. Do you want
this?
Longer version:
Based on Mathieu's suggestion, I've tested
adding dates within <tvar> tags. This makes
it more complicated the first time you
translate, but should mean that you can
then use a 100% match from the translation
memory every time and just click on it the
same way you do for any other content that
stays exactly the same, instead of manually
having to change the days and months every
new week.
It looks like this:
{#time:<tvar|defualtformat>d
xg</>|<tvar|date1>2017-01-24</>|<tvar|format_language_code>{{CURRENTCONTENTLANGUAGE}}</>}}
which means that I get this when I translate:
{{#time:$defualtformat|$date1|$format_language_code}}.
For Swedish, I can just keep it like that:
Where the English original said "24
January" the Swedish translation will say
"24 januari".
Some languages write dates in another
format. For Mandarin Chinese, the first
time I do a translation I need to change it
to
{{#time:n月j日|$date1|$format_language_code}}
(and the same for $date2 and $date3). I
imagine RTL languages will need to change
something too the first time they translate
this, for example.
All possible options are described here:
https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time
<https://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time>
Pro: Less burden for returning translators.
You translate this once, whether you change
the date format or not, then you just click
on the translation in the translation
memory next week.
Con: More complicated. More difficult for
new translators, especially if the standard
format doesn't match the norms of their
language.
The question: Do you want this, or did you
prefer it the way it was? This is all about
making it as easy as possible for you, so
you decide.
https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=page-Tech%2FNews%2F2017%2F04&action=page
<https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=page-Tech%2FNews%2F2017%2F04&action=page>
https://meta.wikimedia.org/wiki/Tech/News/2017/04
<https://meta.wikimedia.org/wiki/Tech/News/2017/04>
//Johan Jönsson
--
_______________________________________________
Translators-l mailing list
[email protected]
<mailto:[email protected]>
https://lists.wikimedia.org/mailman/listinfo/translators-l
<https://lists.wikimedia.org/mailman/listinfo/translators-l>
_______________________________________________
Translators-l mailing list
[email protected]
<mailto:[email protected]>
https://lists.wikimedia.org/mailman/listinfo/translators-l
<https://lists.wikimedia.org/mailman/listinfo/translators-l>
_______________________________________________
Translators-l mailing list
[email protected]
<mailto:[email protected]>
https://lists.wikimedia.org/mailman/listinfo/translators-l
<https://lists.wikimedia.org/mailman/listinfo/translators-l>
--
Haytham Abulela ALY Certified member of the
Society of Translators and Interpreters of
British Columbia (STIBC) (EN>AR)
<http://www.stibc.org/page/certified%20member%20directory/ezlist_member_1f249e57-9d21-47fc-8d39-11a26d993a66.aspx?_s=http%3a%2f%2fwww.stibc.org%2fpage%2fcertified+member+directory.aspx>
Arab Professional Translators' Society certified
member (#10850)
<http://www.arabtranslators.org/Certification/certified_members_801_900.aspx>
Certified member at Egyptian Translators
Association (EGYTA)
<http://www.egyta.com/k2-showcase/k2-latest-item/letter-h/letter-hn>
Profile on LinkedIn
<http://ca.linkedin.com/in/haythamhammam> Profile
on ProZ.com <http://www.proz.com/translator/895138>
Please consider your environmental
responsibility. Before printing this e-mail
message, ask yourself whether you really need a
hard copy.
_______________________________________________
Translators-l mailing list
[email protected]
<mailto:[email protected]>
https://lists.wikimedia.org/mailman/listinfo/translators-l
<https://lists.wikimedia.org/mailman/listinfo/translators-l>
_______________________________________________
Translators-l mailing list
[email protected]
<mailto:[email protected]>
https://lists.wikimedia.org/mailman/listinfo/translators-l
<https://lists.wikimedia.org/mailman/listinfo/translators-l>
_______________________________________________
Translators-l mailing list
[email protected]
<mailto:[email protected]>
https://lists.wikimedia.org/mailman/listinfo/translators-l
<https://lists.wikimedia.org/mailman/listinfo/translators-l>
_______________________________________________
Translators-l mailing list
[email protected]
<mailto:[email protected]>
https://lists.wikimedia.org/mailman/listinfo/translators-l
<https://lists.wikimedia.org/mailman/listinfo/translators-l>
_______________________________________________ Translators-l
mailing list [email protected]
<mailto:[email protected]>
https://lists.wikimedia.org/mailman/listinfo/translators-l
<https://lists.wikimedia.org/mailman/listinfo/translators-l>
_______________________________________________
Translators-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/translators-l
