Localization discussions

[Attn Admin] Can I refer to a file in the media library of another locale?

  • 9 Replies
  • Last reply by milupo
  1. milupo
    milupo 75 posts
    more options

    Hi,

    is it possible to refer to a file in the media library of another locale? I'd like to include screenshots of other operating systems that I don't have. I have still Win XP but I'd like to include screenshots of other Windows versions from e.g. the German media library. Or need I to download the German screenshot and reload it to a Sorbian media library? Of course, only if the German team doesn't have any objections.

    Thanks.

    Michael

    Hi, is it possible to refer to a file in the media library of another locale? I'd like to include screenshots of other operating systems that I don't have. I have still Win XP but I'd like to include screenshots of other Windows versions from e.g. the German media library. Or need I to download the German screenshot and reload it to a Sorbian media library? Of course, only if the German team doesn't have any objections. Thanks. Michael
  2. John99
    John99 3665 posts
    more options

    Hi Micael The files are normally first of all uploaded to the gallery so you should be able to use them. Can you give examples if you are having problems with this. Give the link to the article you are trying to edit and the article that contains the screenshots you would like to use.

    Often the en-US article will have a screenshot, is that the case with the articles you are looking at. (Maybe the en-US article would benefit from the German screenshot)

    Hi Micael The files are normally first of all uploaded to the gallery so you should be able to use them. Can you give examples if you are having problems with this. Give the link to the article you are trying to edit and the article that contains the screenshots you would like to use. Often the en-US article will have a screenshot, is that the case with the articles you are looking at. (Maybe the en-US article would benefit from the German screenshot)
  3. milupo
    milupo 75 posts
    more options

    Hi John99,

    thank you for your reply.

    Yes, I have an example. The English article What is the Mozilla Maintenance Service? has the Upper Sorbian translation Što je wothladowanska słužba (Maintenance Service) Mozilla? and the German translation Was ist der Mozilla-Wartungsdienst (Maintenance Service)?

    The article contains a screenshot of the User Account Control. Unfortunately, a Sorbian Windows OS doesn't exist. All Sorbs have to use a German Windows. By default all translations use English screenshots. But, it isn't user-friendly for Sorbian users to show them screenshots with English text. Therefore I want to use German screenshots if possible. In this case, I want to use the screenshot "ohne Benutzerkontensteuerung" (Image:ohne Benutzerkontensteuerung) instead of English screenshot "no UAC" (Image:no UAC).

    I have Windows XP that doesn't have the User Account Control module. So I cannot make a screenshot and have to take a screenshot from another locale, in this case from the German locale.

    So, now my question: How can I refer in the Upper Sorbian article to the German screenshot without downloading it from the German Media library and uploading to the Upper Sorbian library? I tried such things like:

    de:Image:ohne Benutzerkontensteuerung and Image:de:ohne Benutzerkontensteuerung

    But these don't work.

    Thanks.

    Michael

    Hi John99, thank you for your reply. Yes, I have an example. The English article [[What is the Mozilla Maintenance Service?]] has the Upper Sorbian translation [https://support.mozilla.org/hsb/kb/sto-je-wothladowanska-sluzba-mozilla Što je wothladowanska słužba (Maintenance Service) Mozilla?] and the German translation [https://support.mozilla.org/de/kb/was-ist-der-mozilla-wartungsservice Was ist der Mozilla-Wartungsdienst (Maintenance Service)?] The article contains a screenshot of the User Account Control. Unfortunately, a Sorbian Windows OS doesn't exist. All Sorbs have to use a German Windows. By default all translations use English screenshots. But, it isn't user-friendly for Sorbian users to show them screenshots with English text. Therefore I want to use German screenshots if possible. In this case, I want to use the screenshot "ohne Benutzerkontensteuerung" ('''Image:ohne Benutzerkontensteuerung''') instead of English screenshot "no UAC" ('''Image:no UAC'''). I have Windows XP that doesn't have the User Account Control module. So I cannot make a screenshot and have to take a screenshot from another locale, in this case from the German locale. So, now my question: How can I refer in the Upper Sorbian article to the German screenshot without downloading it from the German Media library and uploading to the Upper Sorbian library? I tried such things like: '''de:Image:ohne Benutzerkontensteuerung''' and '''Image:de:ohne Benutzerkontensteuerung''' But these don't work. Thanks. Michael
  4. John99
    John99 3665 posts
    more options

    Sorry Michael, I did not find the solution. I guess for now it is back to your original plan of downloading the image and uploading it again.


    There is an issue on the fora with spacing. English uses [[Image:No UAC]] to get this No UAC German uses [[Image:ohne Benutzerkontensteuerung]] and they have it linked to https://support.mozilla.org/de/gallery/image/9345

    I had expected HTML to work 

    <img src="link"> 
<img src="support.mozilla.org/de/gallery/image/9345"> 
but that gives a not found. Presumably it violates some security protocol

    I did note using the cdn worked but that is probably not a good or stable solution https://support.cdn.mozilla.net/media/uploads/gallery/images/2012-04-25-13-00-20-35a033.png

    Hopefully someone actually involved with L10n will post the correct solution.

    Sorry Michael, I did not find the solution. I guess for now it is back to your original plan of downloading the image and uploading it again. There is an issue on the fora with spacing. English uses <nowiki>[[Image:No UAC]] to get this </nowiki> [[Image:No UAC]] German uses <nowiki> [[Image:ohne Benutzerkontensteuerung]] </nowiki> and they have it linked to https://support.mozilla.org/de/gallery/image/9345 I had expected HTML to work <nowiki><img src="link"></nowiki> <nowiki><img src="support.mozilla.org/de/gallery/image/9345"></nowiki> but that gives a not found. Presumably it violates some security protocol <img src="support.mozilla.org/de/gallery/image/9345"> I did note using the cdn worked but that is probably not a good or stable solution https://support.cdn.mozilla.net/media/uploads/gallery/images/2012-04-25-13-00-20-35a033.png <img src="http://support.cdn.mozilla.net/media/uploads/gallery/images/2012-04-25-13-00-20-35a033.png"> Hopefully someone actually involved with L10n will post the correct solution.
  5. milupo
    milupo 75 posts
    more options

    Thank you John99.

    I downloaded and uploaded the image now and hope that there will be a more comfortable solution in future.

    Michael

    Thank you John99. I downloaded and uploaded the image now and hope that there will be a more comfortable solution in future. Michael
  6. vesper
    vesper 1182 posts
    more options

    Hey everyone,

    This is an important piece of feedback/design that we need to make sure we get right on the new platform.

    Since we are no longer developing Kitsune, we will not change anything in the current setup. The download/upload a copy solution is the best workaround for this, like John99 said.

    By the looks of it, we should have ONE media gallery that ANY KB will be able to pull content from into the articles. This should significantly lower the technical complexity of media gallery setup, as long as we keep a clear naming convention for the image files.

    I think that post-migration, the best practice should be one name (in English) for all versions of an image, with the language code attached to it, either in front, or at the back.

    • image_name_goes_here_XX.png
    • XX_image_name_goes_here.png

    I think both naming conventions have their pros and cons regarding organization of content, but would vote for the first one - it's easier to see which locales are(n't) there.

    What do you think?

    Hey everyone, This is an important piece of feedback/design that we need to make sure we get right on the new platform. Since we are no longer developing Kitsune, we will not change anything in the current setup. The download/upload a copy solution is the best workaround for this, like John99 said. By the looks of it, we should have ONE media gallery that ANY KB will be able to pull content from into the articles. This should significantly lower the technical complexity of media gallery setup, as long as we keep a clear naming convention for the image files. I think that post-migration, the best practice should be one name (in English) for all versions of an image, with the language code attached to it, either in front, or at the back. * image_name_goes_here_XX.png * XX_image_name_goes_here.png I think both naming conventions have their pros and cons regarding organization of content, but would vote for the first one - it's easier to see which locales are(n't) there. What do you think?
  7. John99
    John99 3665 posts
    more options

    Hi Michał, I am probably not the best person to comment on this but my 2 pennies:

    First of all a question. Presumably en-US gallery images work ok in all locales with the en-US image name. So if someone localising an article leaves the image markup as it is it works but gives an en-US image.

    Secondly it may be a case of swings and roundabouts but I see major advantages in having galleries on a locale level. The obvious main one is that the gallery is specific to that locale and far more convenient to search. The en-US gallery currently showing as 438 pages of images is going to swamp any other locale. Locales will not localise all articles or all images in the articles they do localise. I am also unsure of the complexity issue. Combining the gallery in to one locale is likely to result in duplications of image names &/or potentially break links - not just the image itself, but the articles the image is used in.

    Also locales probably want to take images from other locales in some order of priority, possibly for example the second language of the locale is not English or even a left to right language. Middle East or Eastern locales may be interested in a small number of none-US/European locales.

    For Lithium developers it is probably relatively trivial on migration to expose a suitable permalink for each gallery image.

    Even having to download and upload an image is easy for a contributor to do. A lot quicker probably that creating the image from scratch: Something a contributor may well not be able to do if it is a different OS or device.

    Having a single Gallery with unified naming forces Locales to search in English for the images, and use English image names in their own articles ! that is a backwards step even though localisers are multilingual.

    Hi Michał, I am probably not the best person to comment on this but my 2 pennies: First of all a question. Presumably en-US gallery images work ok in all locales with the en-US image name. So if someone localising an article leaves the image markup as it is it works but gives an en-US image. Secondly it may be a case of swings and roundabouts but I see major advantages in having galleries on a locale level. The obvious main one is that the gallery is specific to that locale and far more convenient to search. The en-US gallery currently showing as 438 pages of images is going to swamp any other locale. Locales will not localise all articles or all images in the articles they do localise. I am also unsure of the complexity issue. Combining the gallery in to one locale is likely to result in duplications of image names &/or potentially break links - not just the image itself, but the articles the image is used in. Also locales probably want to take images from other locales in some order of priority, possibly for example the second language of the locale is not English or even a left to right language. Middle East or Eastern locales may be interested in a small number of none-US/European locales. For Lithium developers it is probably relatively trivial on migration to expose a suitable permalink for each gallery image. Even having to download and upload an image is easy for a contributor to do. A lot quicker probably that creating the image from scratch: Something a contributor may well not be able to do if it is a different OS or device. Having a single Gallery with unified naming forces Locales to search in English for the images, and use English image names in their own articles ! that is a backwards step even though localisers are multilingual.
  8. milupo
    milupo 75 posts
    more options

    May be Wikipedia solution could be applicable. Wikipedia enables uploading images to both the local Wikipedia and the Commons project, a media files wiki project. Image authors can select from Wikipedia languages and add the image description in the selected languages. All screenshots would be in one repository, English ones and locale specific ones. I could specifiy screenshots for Sorbian SUMO articles in English, German, Upper Sorbian and Lower Sorbian. So I could find my own screenshots in four languages but also the screenshots from other locales. The wiki project Commons uses an own name space: "commons:" All media files would have the same name space because they all are in the same repository and can be used in SUMO articles of all SUMO locales.

    May be Wikipedia solution could be applicable. Wikipedia enables uploading images to both the local Wikipedia and the Commons project, a media files wiki project. Image authors can select from Wikipedia languages and add the image description in the selected languages. All screenshots would be in '''one''' repository, English ones and locale specific ones. I could specifiy screenshots for Sorbian SUMO articles in English, German, Upper Sorbian and Lower Sorbian. So I could find my own screenshots in four languages but also the screenshots from other locales. The wiki project Commons uses an own name space: "commons:" All media files would have the same name space because they all are in the same repository and can be used in SUMO articles of all SUMO locales.
  9. John99
    John99 3665 posts
    more options

    As we were initially due to launch Lithium a week or so ago and are now planning to launch early in January perhaps we may have an update on this subject please. Are you now able to explain

    • How Gallery images are handled, where they are stored ?
    • How contributors can test this out ?
    • Will existing Gallery images be migrated, or only those embedded in other content.
    • Where are the draft guidelines, documents and threads relevant to L10n & Lithium
    • When is the change in procedures and software planned for now ?
      Any tentative dates ?
      Is it still only a few weeks away ?

    I will add [Attn Admin] to this thread title

    As we were initially due to launch Lithium a week or so ago and are now planning to launch early in January perhaps we may have an update on this subject please. Are you now able to explain * How Gallery images are handled, where they are stored ? * How contributors can test this out ? * Will existing Gallery images be migrated, or only those embedded in other content. * Where are the draft guidelines, documents and threads relevant to L10n & Lithium * When is the change in procedures and software planned for now ? <br/>Any tentative dates ? <br/>Is it still only a few weeks away ? I will add [Attn Admin] to this thread title
  10. milupo
    milupo 75 posts
    more options

    Hi John99: For your information only. Meanwhile I have Windows 10 Pro, so I can make screenshots of my own computer because I'm up-to-date. But the issue continues to exist for other Windows versions, Linux, and Mac.

    Hi John99: For your information only. Meanwhile I have Windows 10 Pro, so I can make screenshots of my own computer because I'm up-to-date. But the issue continues to exist for other Windows versions, Linux, and Mac.