[gnome-maps] Created branch gnome-43
The branch 'gnome-43' was created pointing to: 789b6f9... Release 43.0 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
String announcement for Maps
Hi! There will be 3 new strings for Maps: These relate to the migration to use an AdwAboutDialog, showing headers in the "Legal" section for data providers: - "Map Data Provider" Section header for map data copyright (mentioning OpenStreetMap and contributors. - "Map Tile Provider" Section header for showing contribution for map tile provider, the service serving pre-rendered map tiles. - "Search Provider" Section header for showing contribution for the search provider service. See also this MR: https://gitlab.gnome.org/GNOME/gnome-maps/-/merge_requests/240 Cheers! //Marcus ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
gnome-maps' default branch is now "main"
Hi! Just wanted to inform that Maps has now changed the default branch from "master" to "main". //Marcus ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-maps] Created branch gnome-42
The branch 'gnome-42' was created pointing to: 938c8b3... Release 42.0 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Retroactive string break request
Hi! I'm sorry, I added a last-minute change in Maps saving the state of showing the scale (we already had a keyboard shortcut to toggle showing the map scale, but it was always shown when starting). I completely forgot that adding the new gschema adds new strings for i18n. So, since there's already been some translations committed since this, I retroactively request a string freeze break. The added schema looks like this: true Show scale Whether to show the scale. So there's the summary and description string for this. Sorry for the inconvenience. //Marcus ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-maps] Created branch gnome-41
The branch 'gnome-41' was created. Summary of new commits: aa952a2... Post-release version bump ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Small whitespace fix in one string in Maps
Hi! Just to inform, there was a small correction, adding a missing space in one string in gnome-maps: src/osmEditDialog.js (line 160): "Contact e-mail address for inquiries. " "Add only email addresses that are intended to be publicly used." Adding a missing space after the first full stop (end of the first sentence) in string. //Marcus ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Rounding numbers in locale friendly way
Hi!
In Maps we display population numbers in the place bubbles (typically
for places like towns, cities, states and so on) based on the
"population" tag from the OpenStreetMap database.
In a some cases, where population numbers are more like estimates, this
number can be rounded, say to the nearest 100k.
Currenly we display the number just a normal integer, using the user's
locale.
So, in a cases, where let's say a city is tagged population=120
it would be displayed: 1,200,000 in English (and so on, 1 200 000 e.g.
in Swedish).
I have played with the idea to try to "detect" when it's an estimate.
For example, something like:
if population "an even multiple of 100":
display _("%s M") where %s is population / 100 with one significant
digit.
if population > 100 and "an even mulitple of 10"
display _("%s M") where %s is population / 100 with two significant
digits (e.g. one decimal digit).
otherwise just display the number locale-formatted (like is done
today).
Does this make sense? Or would this assumption that millions "M" is an
appropriate concept cause trouble in some languages?
I guess the these would also be using ngettext (with the even muliples
of one million as "n".
//Marcus
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-maps] Created branch gnome-40
The branch 'gnome-40' was created. Summary of new commits: 3a7fed1... Post-release version bump ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-maps] Created branch gnome-3-38
The branch 'gnome-3-38' was created pointing to: 7472299... Update Latvian translation ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-maps] Created branch gnome-3-36
The branch 'gnome-3-36' was created pointing to: a807f29... Update Norwegian Bokmål translation ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-maps] Created branch gnome-3-34
The branch 'gnome-3-34' was created pointing to: 496d378... Update Italian translation ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-maps] Created branch gnome-3-32
The branch 'gnome-3-32' was created pointing to: c85fd42... Release 3.32.0 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-maps] Created branch gnome-3-30
The branch 'gnome-3-30' was created pointing to: 22a3457... Update Russian translation ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
String freeze break request for gnome-maps 3.28
Hi! Piotr Drąg found an issue with gettext not really working well with escaped character (using
[gnome-maps] Created branch gnome-3-28
The branch 'gnome-3-28' was created pointing to: ccfaa62... Release 3.28.0 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Bug status Bugzilla
lör 2017-10-07 klockan 09:58 +0200 skrev Hannie Dumoleyn: > Hello, Does anyone know how to change a bug status in Bugzilla? The following bug https://bugzilla.gnome.org/show_bug.cgi?id=752268 was fixed a long time ago (2015). The status should be: FIX COMMITED, but I am not allowed to change the status. Hannie Gnome Dutch Traqnslators I guess normally in Bugzilla you're only allowed to change status of bugs if you're an administrator for the product, or you have created the bug (AFAIR). //Marcus > ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-maps] Created branch gnome-3-26
The branch 'gnome-3-26' was created pointing to: 2389cd3... Release 3.26.0 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Position of "latin" items in lists in RTL-locale contexts
tis 2017-05-16 klockan 11:43 +0430 skrev mousavi.ar...@gmail.com:
> On Tue, May 16, 2017 at 1:40 AM, Marcus Lundblad <m...@update.uu.se>
> wrote:
> > Hi!
> >
> > Thanks for your answer Arash!
> > I attached a patch to the aforementioned bug which I think should
> > do
> > achieve the goal (embedding each component with the RLM or LRM
> > depending on the locale). From some quick testing it kinda looks
> > right
> > to me. But it would be great with more testing (I might very well
> > be
> > missing something obvious here).
>
> I don't have much experience with compiling gnome's development apps,
> but if you could give me some hints I could give some feedback too.
>
>
Which distro are you using?
If you are enable to run flatpaks, you should be able to follow the
newcomer guide for building as a flatpak using gnome-builder, something
like https://blogs.gnome.org/chergert/2016/11/30/contribute-to-polari-w
ith-this-one-simple-trick/ but replace with the gnome-maps code
instead.
//Marcus
> On Tue, May 16, 2017 at 11:31 AM, Claude Paroz <cla...@2xlibre.net>
> wrote:
> > What about just offering the whole expression to translate: "%s →
> > %s".
> > Someone should check that the printf syntax ("%2$s ← %1$s") is
> > properly
> > handled in JS code.
>
> I think that still won't work unless we force the context to be RTL,
> but GTK decides the text direction automatically based on the first
> character of the sentence.
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Position of "latin" items in lists in RTL-locale contexts
tis 2017-05-16 klockan 09:01 +0200 skrev Claude Paroz:
> Le 15. 05. 17 à 23:10, Marcus Lundblad a écrit :
> > tis 2017-05-16 klockan 00:30 +0430 skrev mousavi.ar...@gmail.com:
> > > On Mon, May 15, 2017 at 11:45 PM, Marcus Lundblad <m...@update.uu.s
> > >
> > > Best Wishes,
> > > Arash
> > >
> > > [1] https://en.wikipedia.org/wiki/Right-to-left_mark
> >
> > Hi!
> >
> > Thanks for your answer Arash!
> > I attached a patch to the aforementioned bug which I think should
> > do
> > achieve the goal (embedding each component with the RLM or LRM
> > depending on the locale). From some quick testing it kinda looks
> > right
> > to me. But it would be great with more testing (I might very well
> > be
> > missing something obvious here).
>
> What about just offering the whole expression to translate: "%s →
> %s".
> Someone should check that the printf syntax ("%2$s ← %1$s") is
> properly
> handled in JS code.
>
> Claude
I'm not sure that would work, since the strings could be names written
in either an LTR or RTL script, so depending on the first one, the
overrall direction of the rendered string would be affected, thus the
usage of the directional markers in the generated string.
If we assume the example above with the translation of the placeholder
string "%s → %s" to "%2$s ← %1$s" in an Arabic translation, this would
be rendered as expected (if I got it right) in case at least the second
string was a LTR one. But in case %2$s would be a name written in
Arabic letters, this would make the string being rendered from right to
left, so it would come out as:
←
If I'm not completely mistaken.
//Marcus
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Position of "latin" items in lists in RTL-locale contexts
tis 2017-05-16 klockan 00:30 +0430 skrev mousavi.ar...@gmail.com: > On Mon, May 15, 2017 at 11:45 PM, Marcus Lundblad <m...@update.uu.se> > wrote: > > > > I guess this could be achieved by inserting Unicode directional > > override characters in the beginning of the string and at each > > breaking > > arrow to get the right rendering direction. > > > > Does this make sense to someone knowledgeable in RTL writing > > systems? > > Hi Marcus, > > I just checked and putting a RLM[1] character when both or one of the > places are written with RTL characters works fine. However when both > are in latin, the arrow looks reverse since the direction is actually > not changed. So my suggestion is to use the ltr arrow when both > places > are in latin and rtl when one of them are in RTL. Other solution > would > be to place each part separately and force their direction. Something > like and float in HTML and CSS, so each place and the arrow > would be in their own container and you don't rely on the free text > and RLM character. > > Best Wishes, > Arash > > [1] https://en.wikipedia.org/wiki/Right-to-left_mark Hi! Thanks for your answer Arash! I attached a patch to the aforementioned bug which I think should do achieve the goal (embedding each component with the RLM or LRM depending on the locale). From some quick testing it kinda looks right to me. But it would be great with more testing (I might very well be missing something obvious here). //Marcus ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Position of "latin" items in lists in RTL-locale contexts
Hi! In Maps, I started going through some RTL-language-related issues (http s://bugzilla.gnome.org/show_bug.cgi?id=782608). One thing that came to my mind is how we present stored previous route searches in the search results. Currently when matching on a search string we show something like: Place1 → Place2 in the list of search results (along with an icon indicating the vehicle type, or walking being used). The arrow here is hard-coded. So, the naïve thing to do for RTL-languages is to just reverse the arrow. But thing will get more complicated when a result contains place names written in an LTR script (such as latin). Am I correct in assuming that under an RTL locale (such as Arabic or Hebrew), correct way to present the above example (assuming Place1 and Place2 are latin-script names) would be something like: Place2 ← Place1 I guess this could be achieved by inserting Unicode directional override characters in the beginning of the string and at each breaking arrow to get the right rendering direction. Does this make sense to someone knowledgeable in RTL writing systems? //Marcus ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-maps] Created branch gnome-3-24
The branch 'gnome-3-24' was created pointing to: fe79c6a... Release 3.24.1 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions in gnome-maps
mån 2017-02-20 klockan 21:18 +0100 skrev Marcus Lundblad: > Hi! > > Due to a mishap with marking of pluralized strings in gnome-maps > (https > ://bugzilla.gnome.org/show_bug.cgi?id=778786) I have pushed a fix for > this, and thus introduced new strings (pluralized versions of the > three > time-indicating strings, also took the opportunity to add some more > translator comments). > > //Marcus Unformtunatly, an error had snuck into one of the format strings, so I had to push a fix, thus changing a string. //Marcus > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > https://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions in gnome-maps
Hi! Due to a mishap with marking of pluralized strings in gnome-maps (https ://bugzilla.gnome.org/show_bug.cgi?id=778786) I have pushed a fix for this, and thus introduced new strings (pluralized versions of the three time-indicating strings, also took the opportunity to add some more translator comments). //Marcus ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
UI and string changes in gnome-maps
Hi! We are making a couple of changes to gnome-maps past UI freeze (after approval from the release team). The first is the public transit feature: https://bugzilla.gnome.org/sho w_bug.cgi?id=755808 This has just landed in master, but the feature will not be immediately visible to end users, unless they set a debug environment variable, until we enable the feature via the downloaded service file (which is also used for the map tile addresses). I have demoed this feature in my blog (and mirrored on p.g.o) https://m l4711.blogspot.se/ There's some new strings: For the search interface: "Leave Now" - indicates searching for the next available transit trip "Leave By" - indicates searching for transit trips departuring at earliest a particular time "Arrive By" - indicating searching for transit trips arriving no later than a particular time "Show" - Header in an options popover to select preferred modes of transit Strings for selecting preferred modes of transit "Buses", "Trams", "Trains", "Subway", and "Ferries" In the results list: "Start" - Header indicating start of a journey, this string also has a variant "Start at %s" where %s is known place name. "Arrive" and "Arrive at %s" - for arriving in a journey. "Show walking instructions" - tooltip on a button to reveal detailed walking instructions on a leg of transit journey "Show intermediate stops and information" - tooltip on a button to reveal a list of intermediate stops passed by and further information for a leg of a transit journey. Error strings: "No timetable data found for this route" - indicates that we no timetable data available for the particular route. The other feature (which hasn't landed in master yet) adds an additional button to reverse a route: https://bugzilla.gnome.org/show_b ug.cgi?id=777559 This feature doesn't introduce any additional strings. //Marcus ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Ammend after "Send to repository" in D-L ?
lör 2016-02-13 klockan 09:39 +0100 skrev Claude Paroz: > Le 12. 02. 16 18:57, Rafael Fontenelle a écrit : > > Hi there! > > > > When applying action "Send to repository" after proofread on D-L , > > I > > oftenly forgets to select correct author (not the reviewer, but the > > translator). I'm looking for a way to ammed this commit, in order > > to log > > the correct author. Is it possible? > > > > P.s.: I have a git account. > > Hello Rafael, > > Unfortunately not, once a commit has been pushed to a public > repository, > you cannot amend it any longer. It is technically possible, but that > would mean rewriting repo history, which would then corrupt all > existing > checkouts in the wild. I'm quite sure that the GNOME git repository > is > preventing that. > > Claude Yeah, that's right. We only allow rewriting history for work-in-progress branches, not on master for the reasons Claude mentioned. //Marcus ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Translations of opening hours strings in gnome-maps!
Hi! I gnome-maps we are working on translating the opening hours tags from OpenStreetmap. There is a bug with a patch to turn the OSM tag data in a translatable string here: https://bugzilla.gnome.org/show_bug.cgi?id=740836 We would probably need some extra pairs of i18n-oriented eyes looking at this. The code in the patch is quite hairy, I have tried explaining it in the bug report and in code comments in the code (in src/translations.js). It works by essentially breaking up the tag value into parts in several steps and at each step passing the recursive values through a translatable string format pattern (such as C_(list spec, %s %s) for a list with two args). Comments and suggestions if there is something I'm missing or something that might be problematic regarding translation would be much appreciated. //Marcus ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
