Subscribe to this thread
Home - General / All posts - New Portuguese translation
Dimitri


7,413 post(s)
#06-Mar-20 14:32

There's a new Portuguese localization file, which is complete with Builder, value, etc. tags. This was contributed by a group of students (be gentle...), not all of whom are familiar with GIS, so it could use some review by Manifold users who are native Portugeuse speakers. But it's a good start and appears to have been updated to 171 level (!).

Attachments:
ui.pt.txt

HMS
185 post(s)
#06-Mar-20 18:13

Hi Dimitri, perhaps I could have a go at this (even if I'm way more used to the english GIS terms).

Nevertheless, I followed the procedures in the following link and I can't seem to make the translated ui file work: http://manifold.net/doc/mfd9/index.htm#example__add_a_computed_field_to_a_table.htm

I've tried placing the file under bin64 (together with manifold.exe) and also in the bin folder but nothing happend. Am I missing something?

Also, is there any limitation with the use of accentuation in the ui file?

Currently there is none in the available pt file.

vincent

1,972 post(s)
#06-Mar-20 18:47

I've tried placing the file under bin64 (together with manifold.exe)

That should be good. Be sure to use this .exe file to launch Manifold after. Also, be sure to be in the M9 folder and not in the M8 folder (like I did).

Also, is there any limitation with the use of accentuation in the ui file?

There is a lot in the french ui file, so there should be none.

tjhb
10,094 post(s)
#06-Mar-20 19:08

One more requirement, from the release notes for 9.0.170.last:

The Options dialog allows specifying a localization to use. The choices are: (auto) = use localization files matching the UI language for the user specified in the OS (previous behavior and the default), (none) = ignore localization files and stick to the built-in English strings, or a specific language. The dialog automatically lists languages for UI.xxx.TXT files found near MANIFOLD.EXE. Switching a language only takes effect after a restart - or in a new instance of Manifold launched after the Options dialog has been closed.

So if you use e.g. an English (US) system locale, you need to pick Portuguese manually in the options dialog.

Dimitri


7,413 post(s)
#07-Mar-20 02:38

To follow up on what Tim said, the key question is what Windows is set to. Windows has a localization system that is designed to help applications automatically use the right language. Manifold respects those Windows settings.

The way that works, if Windows is set to use Portuguese, when you put a ui.pt.txt file in the same folder as the manifold.exe file then Manifold will use that ui.pt.txt file when it launches, and Voila! ... you have Manifold in Portuguese.

But... if Windows is set to use English, then the only language files Manifold will look for on launch are English language files, that is, those that begin with ui.en... such as ui.en.txt or ui.en-US.txt or ui.en-UK.txt and similar. After all, when Windows is telling all applications "Hey guys, we're running in English!" it's not telling all the apps to go look for files in Spanish or Portuguese or whatever.

if your Tools - Options - Localization setting is set to the default, (auto)... that tells Manifold to follow along with whatever Windows says is the language to use. That's what is documented in the current version of the Localization topic, which has yet to be updated to include the ability to force use of a particular localization file.

However, what the Localization topic says to do still works if you have the default setting of (auto):

If you want to continue using Windows in English, but want the translated file to be used for the Manifold UI, save the translated file as ui.en.txt.

I use Windows in English, so when I want to try out a new localization file I do this:

1. Put it into the same folder as manifold.exe.

2. Copy and paste it, and rename the pasted copy ui.en.txt

3. Double-click manifold.exe to launch a new session, using the new localization

When you do that when running Windows in English, Manifold on launch looks around for any English localization files, finds ui.en.txt , and uses that. What's in the file may be Portuguese or French, but Manifold just takes whatever is in the file.

On accentuation, the translators of the file were students who for some reason didn't use it. I don't know why. There is some, but many are missing. The file has some systematic errors which, mercifully, are easy to clean up. For example, somebody did a search and replace for Value to valor without being careful about matching case, so that got replaced in some of the tags. I'm doing some editing now to clean up typos, etc.

Dimitri


7,413 post(s)
#07-Mar-20 05:03

Here is a much better ui.pt.txt file, which has the more common accents added, such as são, ção and ções. It also has errors in tags fixed. No doubt there are more to be found. :-)

Attachments:
ui.pt.txt

Dimitri


7,413 post(s)
#07-Mar-20 10:44

A new ui.pt.txt file, with numerous structural errors, tag errors, and typographical errors corrected.

Attachments:
ui.pt.txt

Dimitri


7,413 post(s)
#07-Mar-20 15:22

Here's one final ui.pt.txt. This has a few dozen more fixes to use of accents, a few errors in tags, typos, etc.

There are still plenty of accents missing and no doubt other errors, but this is much improved over what we started with.

Attachments:
ui.pt.txt

tjhb
10,094 post(s)
#07-Mar-20 22:36

I don't know Portuguese at all, but these entries stand out as strange to me.

BuilderFunctionTileCutBorder=TileCutBorder(<imagem>, <valorx2>, <fronteira>) : <bloco>

BuilderFunctionTileRemoveBorder=TileRemoveBorder(<bloco>, <fronteira>) : <bloco>

DialogEditStyleCtlTabBorder=Fronteira

Would margem, contorno or borda be better for an image (and area format) than fronteira? I could be completely wrong.

(I wonder if Gustavo and Paulo are still around.)

Dimitri


7,413 post(s)
#08-Mar-20 07:44

Good eyes. I think borda is the right word. It seems to be what is used in Portuguese translations of graphics editors in similar contexts, and it is a semi-cognate to the English default.

I guess whoever did those lines did not realize those strings are not used in geographic work, meaning "border" as a "frontier" of a region or country, but in graphics work where "borda" is better.

I don't like the use of "brilho" for "halo" either. The English word "halo" is now used in many technical settings.

tjhb
10,094 post(s)
#08-Mar-20 08:08

Good Dimitri, thanks. You are doing god's work as you know.

(Quite a lot of it!)

Dimitri


7,413 post(s)
#08-Mar-20 08:20

It's a disease.... get into it and hard to pull away. :-)

Here's yet another ui.pt.txt, using borda, and halo. It also has a few dozen corrections of errors plus numerous additions where accents were missing, such as índice.

It seems that the original translators thought the program could not handle accents, so they didn't use those, but just the ordinary character equivalents. Now that hundreds of accented characters have been restored, it's looking better.

Attachments:
ui.pt.txt

HMS
185 post(s)
#08-Mar-20 18:44

Hi Tim and Dimitri, thanks for the notes on getting the ui.pt.txt file to work. In fact, after a restart, Manifold started working wth the portuguese UI file.

I started by reading the translated file in search for typos and accentuation errors and I didn't made a detailed reading of the original expressions (with some exceptions listed bellow). In brief, I would say that the effort of translated this file to portuguese is highly commendable, and I salute you for that, but a literal/direct translation, as expected, usually distorts the original meaning.

After reading the original file and to work within M9 with the translated file I realized that a thorough reading of the original file (english) should be done allowing me to approach the meaning of the translation file to its original meaning. So, this is, indeed, a work in progress, but for now, I made some corrections regarding the following expressions:

  • Downstream literally translates as "rio abaixo", but we have a better portuguese word for that: "jusante" (meaning "towards the river mouth"). The same happens with "Upstream" that can be correctly translated as montante (meaning "towards the source of the river");
  • "Inválido número de valores" should be "Número de valores inválido";
  • "Grid" is better translated as "grelha" instead of grade;
  • "Clip" should be "Corte" instead of lâmina (which is literally translated as blade);
  • "U&ncomment Lines" is better translated as "Eliminar comentário das linhas" (something like "eliminate comment from lines") given that "descomentar" doesn't exist in portuguese language;
  • As for "Branch" I translated it as ramal (it could also be "ramo", but ramal seems better suitted for the gis purpose);
  • "Melhor ajuste (título)" instead of "Melhor ajuste título";
  • "ValueCoordShiftX=Avanço para falso este" should be "Falsa origem da longitude" and "ValueCoordShiftY=False northing" should be "Falsa origem da latitude";
Nevertheless, I have some questions regarding the following words:

  • child: translated as "filho") doesn't work particularly well, given that "filho" is the literal translation of "son". Should the original child designation be mantained?
  • In expressions like "Campo deve ser parte do GROUP BY ou parte do agregado do SELECT de nível superior" should one translate this functions? If so, GROUP BY should be "AGRUPAR POR" and SELECT should be (SELEÇÃO) and this expression should be: "Campo deve ser parte do AGRUPAR PORou parte do agregado da SELEÇÃOde nível superior."

I've also made a significant number of corrections regarding accentuation and some minor typos (that I list bellow here for future reference, well at least some of them):

  • tolerancia = tolerância; distancia = distância; endereco = endereço; intermediario = intermediário; angulo = ângulo; mudanca = mudança; décimas = décimas; raiz cubica reciproca = Raíz Cúbica Recíproca; minusculas = Mínusculas; maiusculas = Maiúsculas; max = máx; min = mín; comecar = começar; ultimo = último; node = nó; ecra = ecrã; parametros = parâmetros; numero = número; graficos = gráficos; laxico = léxico; ambiguo = ambíguo; pagina = página; memoria = memória; proximo = próximo; mantem = mantém; Hidrograficas = hidrográficas; espaco = espaço; rotulo = rótulo; comentario = comentário; orbita = órbita; unico = único; contem = contém (this word is a good reason why the accentuaton is so important in the portuguese language, wihtout accent it means something similar to "to count" and with the accent it changes it meaning to "contains")

Anyhow, like I mentioned earlier this is a work in progress and I really need to work with this file over the following days in order to find out if more corrections are still needed and, if so, to substitute them with the correct "technical" expressions (and meaning).

I'm sending the revised file attached.

Attachments:
ui.pt.txt

Dimitri


7,413 post(s)
#09-Mar-20 07:29

Thanks so much for the comments and improved file! Some answers, comments, etc...

I agree with the issue of literal translations as opposed to translations which capture the meaning in English. That's true for all translation work, where "hot dog" is not literally intended to be mean "roasted canine".

Anyway, when translating the Manifold UI, besides the balance between "literal" and "what it is intended to mean", we also have the additional task of translating jargon, or slang, which be a challenge both in terms of literal meaning and intended meaning. Every technical culture has jargon words, so ultimately we want to use jargon words that are familiar to GIS users and DBMS users given Portuguese technical slang.

Complicating that is that Manifold has its own jargon which sometimes is different than GIS jargon as used by ESRI or by other systems. A good example of that is Manifold's use of "area" for objects that are not lines or points, instead of the ESRI word "polygon." Manifold uses "areas" because what ESRI calls "polygons" are not understood to be polygons by most educated people (see the discussion in the Release 8 user topic Terminology in GIS).

So, the correct translation of "area" in Manifold is usually a literal one for the word meaning a 2D region, and is not the translation of "polygon".

"Grid" is better translated as "grelha" instead of grade;

I think "grade" was used because programming/DBMS jargon seems to use "grade" for "grid", at least in some prominent settings. For example, if you look at the Visual Studio documentation in Portuguese, you see that Microsoft translates "Data Grid View" as "Exibição em Grade de Dados." Microsoft, of course, makes mistakes from time to time, but given that they have a lot of influence on technical people in Windows, if you use "grade" then programmers and DBMS people will know you mean "grid" in the sense that Manifold uses it, a row/column display.Does that seem reasonable?

"Clip" should be "Corte" instead of lâmina (which is literally translated as blade);

I think "clip" or "Clip" occur in settings such as...

BuilderFunctionGeomClip=GeomClip(<geom>, <clip>, <inner>, <tolerance>) : <geom>

and

TemplateGeomClip=Clip Individual|Geom:|Clip with:|Tolerance:|Keep inner part

The meaning is different in the two cases although the same English word is used in both . In the first case, "clip" is used as "the cutter" or "the cutting instrument" so "lâmina" was used. In the second case, "clip" is used as a verb, "to cut", where "Cortar com" is good for "Clip with." What do you think of using a noun, perhaps "<cortador>" for similarity with the verb, to translate "<clip>"?

In expressions like "Campo deve ser parte do GROUP BY ou parte do agregado do SELECT de nível superior" should one translate this functions?

No. Those are the names of SQL statements, operators, etc., which do not translate. See the Guidelines for Translators section of the Localization topic.

Thanks for the corrections on accentuation! Those are a big improvement.

---

I can't resist passing on a true story about literal translations...

I remember visiting a Spanish speaking country years ago when on a hot day I saw an advertisement at a kiosk for "milk shakes," so I ordered one. The man put some milk into a cocktail shaker, shook it a few times, and put it into a glass. Done! :-) I thanked him and drank it, and then I politely explained that the English word for the thing was not to be taken literally, that it was not milk shaken, but a drink made by vigorously mixing a high proportion of ice cream with a bit of milk - no shaking involved. He didn't believe me, insisting the translation was correct and hence that is what he was bound to provide. No doubt in modern times he would have pulled out a telephone and cited Google Translate to prove his point. Sigh!

HMS
185 post(s)
#08-Mar-20 18:53

Hi Tim, margem (or even contorno) is, indeed a better translation for this purpose. Borda also means something similar but usually it is used in a different context.

Dimitri


7,413 post(s)
#09-Mar-20 07:45

Hmm... well, I think it depends on the context. Maybe you need both "margem" and "borda" to cover the different uses of "border" in Manifold.

Consider Tim's post:

BuilderFunctionTileCutBorder=TileCutBorder(<imagem>, <valorx2>, <fronteira>) : <bloco>

BuilderFunctionTileRemoveBorder=TileRemoveBorder(<bloco>, <fronteira>) : <bloco>

DialogEditStyleCtlTabBorder=Fronteira

It seems that "borda" is pretty popular in various translations of graphic layout, word processing, etc., applications, in settings where it means what "Border" means in the DialogEditStyleCtlTabBorder tag, for example, in Style and Layout contexts in Manifold.

LibreOffice in Brazilian Portuguese, for example, has many uses like:

Não confunda a borda do quadro com os limites do texto que podem ser visualizados usando o menu Exibir

and

Definindo uma tabela de duas colunas sem borda e título

But those are all cases where they mean the border of a table or of a frame, not the margins of a sheet of paper.

They also have plenty of uses of "margem" in contexts meaning more like the context of the BuilderFunctionTileCutBorder and BuilderFunctionTileRemoveBorder tags, for example,

Definir uma margem ao redor de um objeto como se fosse uma fotografia.

So maybe it would be good to use "margem" for those and "borda" for the other cases?

HMS
185 post(s)
#09-Mar-20 14:08

Hi Dimitri, I'll try to address all the topics.

It seems that "borda" is pretty popular in various translations of graphic layout, word processing, etc., applications, in settings where it means what "Border" means in the DialogEditStyleCtlTabBorder tag, for example, in Style and Layout contexts in Manifold.

LibreOffice in Brazilian Portuguese, for example, has many uses like:

Não confunda a borda do quadro com os limites do texto que podem ser visualizados usando o menu Exibir

That's a tough example Dimitri, I can assure you that in portuguese language we don't use that word in this context. In the previous example I believe "moldura" (that can literally be translated also as frame) or "contorno" are better words for the purpose (of course "borda" can also have this meaning, but it's just a really far-fetched term for this purpose). I'll not advise the use of borda in this context.

This line of thought also applies to the following example:

I think "grade" was used because programming/DBMS jargon seems to use "grade" for "grid", at least in some prominent settings. For example, if you look at the Visual Studio documentation in Portuguese, you see that Microsoft translates "Data Grid View" as "Exibição em Grade de Dados." Microsoft, of course, makes mistakes from time to time, but given that they have a lot of influence on technical people in Windows, if you use "grade" then programmers and DBMS people will know you mean "grid" in the sense that Manifold uses it, a row/column display.Does that seem reasonable?

It is reasonable, and most portuguese speakers will understand what you mean, but, again, it's just a possible translation and I believe a more common one in brazilian portuguese (more on this subject later). For me it's definitely not an "easy" term in this context.

I think "clip" or "Clip" occur in settings such as...

BuilderFunctionGeomClip=GeomClip(<geom>, <clip>, <inner>, <tolerance>) : <geom>

and

TemplateGeomClip=Clip Individual|Geom:|Clip with:|Tolerance:|Keep inner part

The meaning is different in the two cases although the same English word is used in both . In the first case, "clip" is used as "the cutter" or "the cutting instrument" so "lâmina" was used. In the second case, "clip" is used as a verb, "to cut", where "Cortar com" is good for "Clip with." What do you think of using a noun, perhaps "<cortador>" for similarity with the verb, to translate "<clip>"?

"Cortar com" is a good option for "Clip with", but "cortador" (I believe you refer to the transform operation that appears under the transform pane) just doesn't work (in portuguese "cortador" can mean both "cutting machine" or the "person who cuts meat in a butchery"). In my transform pane where Cortador and Cortador individual appears I would simply replace them with "Corte" and "Corte individual".


In the previous ui.file I mantained the "Label" translation as "Rótulo" (in fact, QGIS uses this terminology) but it seems that "Etiqueta" (like used in ArcGIS) should be a better fit. "Rótulo" can have a more specific portuguese meaning in GIS/CAD layouts, namely refering to the area in the page where you state the specs for the drawing (title, scale, author, owner, developer, ect.). In this line of thougth I believe "etiqueta" is a better translation for "label".

I would also advise to adopt "Intersetar" as the translation for Intersect (it's a literal and better translation than "cruzar" or "cruzando").

I noticed there is also a translation for Median Polish (that by now you can guess was translated as a median citizen of Poland) and I believe you're refering to Tukey's Median, refered in portuguese as "Mediana de Tukey". Is this assumption correct?

As for "Installed with mismatching options" I suggest "Instalado com opções incompatíveis", the present "Instalado com opções que não corresponde" doesn't have a very defined meaning.

In another expression, indeed "teto" means ceiling , but that not translates into something understandable. Do you think it's possible to sum up the "Ceiling up to Decimals" meaning by "Arredondar para cima até às décimas" or even by "Arredondar para valor superior até às décimas" (something like "Rounding to superior value to one decimal place")?


Overall, it seems that the original translation file was based in Brazilian Portuguese, and I can understand the confusion, since Portuguese and Brazilian portuguese are very similar indeed, but they are not the same language, that's why you have the following two libre office versions: Portuguese (Brazil) and português (Brasil) (usually abreviated by Pt-Pt and Pt-Br, or something similar). I believe it can be similar to what happens between En-US and En-UK.

As for further clarification, I'm using the "Acordo Ortográfico da Língua Portuguesa, 1990" (something like Portuguese Spelling Agreement adopted since 2009 and that can be mentioned by AO90). If you have the time to invest in this particular mess, I'll advise the reading of the following link: http://www.portaldalinguaportuguesa.org/acordo.php. Basically, there was an attempt by the portuguese "authorities" to "normalize" the portuguese language across all the different portuguese speaking contries. Official agreements were made between all countries involved, but in the end, besides Portugal, no other country adopted the agreement, ending up with extreme resistance and struggle to implement the agreement in Portugal (our language was previously defined by the Portuguese Spelling Agreement of 1945). Nowadays, the 1990 agreement is more accepted within Portugal (given that over the last 10 years the new generations were teached to write this way in elementary school) and all oficial documentation has to be written with AO90).


In the attached file I corrected a few more words (with accents): Hiperbólico; Círculo; Décima; Médio; Intermédio; Níveis; Divisões; elipsóide.

Attachments:
ui.pt.txt

Dimitri


7,413 post(s)
#09-Mar-20 15:10

Thanks for the info! I haven't digested it all, but let me touch on just one point. You're right, in that the original team was translating from a Brazilian Portuguese background, but also aiming for a broader audience.

In an ideal world, it would be great to come up with a "compromise" file that would work both for Portuguese and Português - Do you think that is possible?

After all, we're talking about captions for commands and some very brief tooltip comments, and nothing particularly literate. I think any translations of user manuals or short "getting started" summaries would have to be split into pt-pt and pt-br, but do you think a UI localization file could work for both?

HMS
185 post(s)
#09-Mar-20 16:50

Yes, I think it's possible to do that for the UI. In fact, I had this in mind when I started working with the ui file and I believe all the suggested corrections will work for both (Pt and Br). So far, the exception could be "grade", but that compromise was what I had in mind when I stated it was a reasonable translation.

But, of course, this varies: for instance, in the Libreoffice example you provided earlier this correlation doesn't happen. In the portuguese libreoffice help file, the word is moldura (and that's what a picture has around it, a moldura (like in frame), not a borda.

HMS
185 post(s)
#09-Mar-20 18:56

(...) that's why you have the following two libre office versions: Portuguese (Brazil) and português (Brasil) (usually abreviated by Pt-Pt and Pt-Br, or something similar). I believe it can be similar to what happens between En-US and En-UK.

After reading this more carefully, the correct sentence should be "(...) Portuguese (Portugal) and Portuguese (Brasil) (usually abreviated by Pt-Pt and Pt-Br, or something similar)."

Dimitri


7,413 post(s)
#11-Mar-20 17:58

Sorry for the delay. new ui.pt.txt attached, incorporating your mods.

I believe "moldura" ... better words for the purpose

borda -> moldura

I would simply replace them with "Corte" and "Corte individual".

Done.

I believe "etiqueta" is a better translation for "label".

Done. Given gender change, should be checked, eg, Novos Rótulos -> Novas Etiquetas, etc.

I would also advise to adopt "Intersetar" as the translation for Intersect

Done.

I noticed there is also a translation for Median Polish (that by now you can guess was translated as a median citizen of Poland) and I believe you're refering to Tukey's Median, refered in portuguese as "Mediana de Tukey". Is this assumption correct?

No. Tukey's Median is a different thing from Median Polish, which was also invented by the ever-prolific Tukey. It's now in there as "Kriging com Mediana Polish" - that's obviously weird, but everybody in English seems to think it has something to do with Poland, so why not... :-) It's a jargon expression, I suppose that could be translated based on "smoothed median" or "median smoothing", or maybe just "Kriging com Mediana (Median Polish)"

As for "Installed with mismatching options" I suggest "Instalado com opções incompatíveis", the present "Instalado com opções que não corresponde" doesn't have a very defined meaning.

Done.

In another expression, indeed "teto" means ceiling , but that not translates into something understandable. Do you think it's possible to sum up the "Ceiling up to Decimals" meaning by "Arredondar para cima até às décimas" or even by "Arredondar para valor superior até às décimas" (something like "Rounding to superior value to one decimal place")?

I don't know. I don't like the original English terms, which I find confusing. Both Ceiling and Ceiling up to Decimals are rounding up. Ceiling rounds up to the next integer. Ceiling up to decimals rounds up to the given number of decimal positions, so it's not just one decimal place. Tough to translate.

Attachments:
ui.pt.txt

HMS
185 post(s)
#12-Mar-20 16:31

Hi Dimitri, thanks for your thoughts on the translation suggestions.

Regarding my previous suggestions, after a more indepth search, I'd like to suggest some changes.

  1. Probably "Recorte" is a better fit than "Corte" for Clip. This is also the designation that QGIS uses for Clip, so I'd suggest "Recorte" e "Recorte Individual".
  2. The Median Polish in portuguese cientific papper is refered to in english "Median Polish" and in the brazilian community some authors use "polimento da mediana". It seems as there's not an established way to approach this term, so probably leaving "Median Polish" could be the most correct option. This way its meaning will not be affected.

In what concerns to more hard choices for the translation I have the following suggestions:

"Sharpen" is currently translated as "Afiar" and "Afiar" means "to sharpen", but comparing with other software, like Photoshop, expressions including this term (like sharpen edges) are usually translated as "Tornar nítido" wich also translates as "sharpen" and I believe could be a better term for it.

"Blur" is currently translated as "Borrão" usually more approprieted to describe something like a "ink blot". Comparing, again, with other software, like Photoshop, expressions with "Blur" are usually translated as "desfoque"" wich also translates as "blur and I believe is a better term for this procedure.

"Weight" is not currently translated and the literal correct translation is "Peso". Given that the help manual describes this operation as able to "Create a point at the approximate center of balance of each object" could it be that instead of "peso" should be something like "Centro de balanço" (Center of Balance)?

Do you think that for better coherence the translation for "TemplateFloorDecs=Arredondar para baixo às Décimas" should be instead "Arredondar para valor inferior até às Décimas" follwoing the approach done for "TemplateTileCeilDecs=Arredondar para valor superior até às Décimas"

I believe that "TemplateTileTruncDecs=Truncar para Décimas|Valor:|Décimas" could be better translated as "TemplateTileTruncDecs=Truncar para Décimas|Valor:|Casas decimais". "Casas decimais" (such as in "Decimal places") is indeed what softwares like libreoffice uses to describe the number of decimal places in a cell.

In the context of the layout options, I believe "moldura" is a better "frame" translation than "quadro". The problem is that this could end up being confusing and strange in expressions like the following, where the same word could have different meanings: "CommandEditShapeAlignBottom=Alinhar com Fundo|Alinhar molduras selecionadas com moldura inferior da moldura ativa."

An easy solution for this could be: "Alinhar molduras selecionadas com o limite inferior da moldura ativa". If you agree with this assumption, this would aplly to the following context (where we have gender changes":

CommandViewLayersFilterLayoutText=Frames de Texto|Mostrar apenas moldura de texto.

CommandViewLayersFilterLayoutText=Caixas de Texto|Mostrar apenas moldura de texto.

CommandEditShape=Alinhar|Editar forma das molduras selecionadas.

CommandEditShapeAlignBottom=Alinhar com Fundo|Alinhar molduras selecionadas com o limite inferior da moldura ativa.

CommandEditShapeAlignLeft=Alinhar à Esquerda|Alinhar molduras selecionadas com o limiteesquerdo da moldura ativa.

CommandEditShapeAlignRight=Alinhar à Direita|Alinhar molduras selecionadas com o limite direita da moldura ativa.

CommandEditShapeAlignTop=Alinhar com Topo|Alinhar molduras selecionadas com o limite superior da moldura ativa.

CommandEditShapeList=Alinhar|Editar forma das molduras selecionadas.

CommandEditShapeResizeToSelected=Redimensionar para seleção|Redimensionar moldura ativa para corresponder às molduras selecionadas.

CommandEditShapeSameFormat=Mesmo formato|Aplicar formato da moldura ativa às molduras selecionadas.

CommandEditShapeSameHeight=Mesma Altura|Redimensionar molduras selecionadas para a mesma altura da moldura ativa.

CommandEditShapeSameWidth=Mesma Largura|Redimensionar molduras selecionadas para a mesma largura da moldura ativa.

CommandEditShapeStackHorz=Empilhar Horizontal|Empilhar molduras selecionadas horizontalmente em torno da moldura ativa.

CommandEditShapeStackVert=Empilhar Vertical|Empilhar molduras selecionadas verticalmente em torno da moldura ativa.


Unfortunately, what's happening with "Ceiling" translation also applies to "Floor", so, for now I don't have a solution for this and probably the english terms should stay until further developments. What do you think?

Meanwhile I found a few more accentless words and also a few more typos: Paineis "Painéis"; rtiquetas "Etiquetas"; função de erro "Função de erro"; Hipnotusa "Hipotenusa"; Modulo "Módulo"; Hiperbolica "Hiperbólica"; Media "Média"; tolerância "Tolerância"; Suave "Suavizar" (Suavizar is the verb, while Suave is the adjective); Inicio "Início"; Semelhanca "Semelhança"; Mes "Mês"; Modulo "Módulo"; Positição "Posição"; a "à" (like in "align left")..


This is still a work in progress, but I believe we're getting there!

UI file attached.

Attachments:
ui.pt.txt

HMS
185 post(s)
#13-Mar-20 22:09

Hi Dimitri, I'm sorry for the delay and the partial file upgrades, but given the premises behind the initial translated UI file, sometimes I need to come across the translated expressions while operating Manifold 9 to understand if they're correct or not.

In fact, the initial lack of accentuation sometimes acted as greater obstacle than what I expected, given the lack of context for a given sentence/expression difficults the understanding of its precise meaning. For instance, the word "ultima" can mean "to finnish" while "última" means "last", but both are spelled correctly. So, reading the UI file was not enough to correct this sort of words, and only when actually updating the UI file and running Manifold 9 I'm able to reach to a conclusion about the right translation. Unfortunately, I found out this takes a while.

Attached you can find an updated file with some more corrections. Some early doubts about a few words are now becoming more clear. For instance, after consulting the Portuguese official authorities website regarding Geodesy, my initial doubt about "grid" translated as "grade" was enlightened and we should opt for "grelha" instead of grade (for instance, "NTv2 Grid" is officially translated as "Grelhas no formato NTv2").

After going through Manifold 9 styles pane, I found out that using "limite" together with "moldura" (instead of only using moldura or the less obvious "borda") really works and I believe its the best option.


Latest changes:

  1. Currently "Path" was not translated as "caminho". This applies to "Impossível inicializar sistema de coordenadas ou caminho de conversão.", "Caminho de conversão de coordenadas inválido" and "ErrorPathInvalid=Caminho inválido.";
  2. "a" (similar to "the") has a diferent meaning than "à" (translated as "to the"). This applies to "ErrorDatabaseCantConnect=Impossível conectar à base de dados.";
  3. Usually, across different applications, Read Only File is translated like "Ficheiro de leitura" instead ou Ficheiros para leitura". This applies to "ErrorFileReadOnly=Ficheiro apenas de leitura."
  4. Grid as grelha (instead of grade) applies to the following. This applies to "ErrorGridSizeTooLarge=Tamanho da grelha é demasiado grande."
  5. "Mais do que" is better written than "Mais que". This applies to "ErrorIndexKeyComposite=Mais do que um campo chave."
  6. I believe "a mais" is a better translation than "demais". This applies to "ErrorItemCantAlloc=Não é possível alocar valor, valores a mais.", "ErrorItemCountTooLarge=Valores a mais."
  7. "e" means "and" while "é" means "is". This applies to "ErrorScriptObjectExpected=Valor não é um objeto.".


A few more corrections regarding mostly typos, acentuation and coherence between upper and lower case:

Elimiar "Eliminar"; moldura "Moldura"; Maiuscula "Maiúscula"; comeca "começa"; Maior or "Maior ou"; Operators "Operadores"; Adicionar a Seleção "Adicionar à Seleção";Calculo "Cálculo"; ultima "última"; especifica "específica"; pixeis "píxeis"; incompativel "incompatível"; ja "já"; Crair "Criar".


Words that should be maintained in english:

The literal translation of "tile" is, indeed, azulejo, but this way it has a strong meaning related to construction, like it happens with decorative tiles. I believe the english word should be maintained.


"ReportCommandFullFetch=Para teste de desempenho, busque todos os valores retornados ou não busque todos os valores retornados." is not a great translation and maybe too long to express something that I believe could be best written as "Ligue ou desligue a pesquisa de todos os valores retornados para teste de desempenho" or even "Ative ou desative a pesquisa de todos os valores retornados para teste de desempenho".


There are also translations across the UI original translated file like "Eliminando" or "Copiando" (something like "Deleting" and "Copying") that are used mostly in Portuguese-Br translations. In a Portuguese-Pt version it'd be "A eliminar" or "A copiar". They mean the same, but this verb tense in Brazil (gerúndio) is widely spread and very common. In Portugal that's not the case. Nevertheless, keeping in mind the purpose of this translation(adjusted for both Pt-Pt and Pt-Br) I kept the existing translation "Eliminando", "Copiando", etc.

The attached UI file already features these suggestions.

Attachments:
ui.pt.txt

Dimitri


7,413 post(s)
#18-Mar-20 13:13

Sorry for the slow reply! Thanks so much for the new file. You are doing God's work!

Some comments...

For instance, after consulting the Portuguese official authorities website regarding Geodesy, my initial doubt about "grid" translated as "grade" was enlightened and we should opt for "grelha" instead of grade (for instance, "NTv2 Grid" is officially translated as "Grelhas no formato NTv2").

"grid" in the program is used in two meanings. One of them is geodesy, where translations like the NTv2 Grid using grelhas make sense. But the other meaning is in the computer programming context and snapping, where I'm worried that grade might be better. What do you think?

I think at this point it is your call, since you have become the de facto bearer of the flame for the Portuguese localization file! :-)

HMS
185 post(s)
#18-Mar-20 15:57

No worries. Manifold GIS has been such a great tool for my work over the years, that I'm not seeing this as work, by any means. I'm just trying to contribute in the best way I can to support Manifold. On other hand, I'm using this time to continue working with Manifold 9 and becoming more familiar with its proceedings. Right now I'm on the verge of completing my first task completely on Manifold 9. So, so far it's a win-win situation ;)

But the other meaning is in the computer programming context and snapping, where I'm worried that grade might be better. What do you think?

I believe you're right. I'll try to investigate a little bit further into the programming context, but, for now, "grade" could be the right approach for this.

Over the last days I found a few more words and/or expressions that should be changed. For instance, over the years with Manifold 8 I became so used to the word "Aspect" (in the original english UI) that only a while after using the translated file I notice that something wasn't "right". In fact, both in Portugal and Brasil this means "Exposição/Orientação de Encostas", so there are some things that still need correction.

I believe by the end of this week or the beggining of the next one I'll have a completed file (or almost completed). I really don't know if there are still portuguese speakers around the forum, but all revision contributions would be welcomed by the time I finnish this task.

HMS
185 post(s)
#26-Mar-20 21:12

Hi Dimitri, here's the updated UI portuguese localization file (regarding the 9.0.171.1 build).

It took me a while to get to the present point, but I had to try it for a few days before sharing it. A lot of the early questions are almost solved, (and they're quite a lot to mention here). If you feel the need to have some explanation regarding some particular word or expression, just mention it and we'll go from there.

For the most challenging expressions/words that can have multiple meanings (like branch (ramo, ramal, ramificação, or even elemento), merge (fundir, juntar, unir, agregar), union (fundir, juntar, unir, agregar)) I went through each menu in order to find out what would be the best fit for these expressions, given the portuguese meaning for these words can be really dependent of the application context.

Also, I found out a few words there weren't completely visible in the pane/menu after translating them. The translation for decimals is a good example of this particular case. For instance, I believe the contextualized translation for this should be "casas decimais" (like in decimal places), but under the transform pane there is not enough space for both words so I went back for "décimas". In every portuguese (Pt or Br) software this is normally adressed as "Number of Decimal Places" or "Decimal Places", so "Décimas" works but "Decimal Places" would be a perfect fit. This also happens with the Web Login menu (after the New Data Source menu) where only "Application" is visible instead of "Application Key:". With this in mind, instead of the correct "Chave da Aplicação" the translated file features the less obvious "Aplicação:" only.

In less complicated translations, it is worth mentioning the "Zoom to Fit" option in the Main Toolbar, given that the portuguese linear translation "Zoom para ajustar" sounds a bit incomplete. After looking for it in the Help (while trying to find out a better expression) I noticed it states "Zoom so the contents of the active layer fill the window". After trying it with a map with an active layer of a small area and another layer with a larger area, I noticed that with a map the zoom effect is better described as a Zoom to All. With this effect in mind, I believe "Zoom para Ver Tudo" is a better fit (QGIS also features an aproximate translation "Ver Tudo").

Attachments:
ui.pt.txt

Dimitri


7,413 post(s)
#27-Mar-20 04:23

Thanks! Looks really super!

Regarding Zoom to Fit vs. Zoom to All. Manifold uses Zoom to Fit because that is slightly (just slightly) better than Zoom to All for maps, which often use image server backgrounds. "All" is a slightly stronger word than "Fit" because it explicitly means "everything," which by logic should include the image server as well.

But, it's not a big deal and this is just computer jargon where terse constructions are perfectly OK. I think both are fine. :-)

I personally think shorter captions that are reasonable mnemonics are OK, while others prefer more grammatical constructions. For example, the "Edit Query" caption that appears in many dialogs often requires too-long text in various languages (in Turkish, for example, Sorguyu Düzenle), and in such cases translators often use just "Query" (in Turkish, Sorgu). That's slightly cheating UI guidelines that recommend having a verb for command captions, but I don't worry about it.

Out of curiosity, if you don't mind my asking, do you use the Tools - Edit Localization File dialog to maintain the file and to add updates?

HMS
185 post(s)
#27-Mar-20 11:10

"All" is a slightly stronger word than "Fit" because it explicitly means "everything," which by logic should include the image server as well.

You're right, I forgot about the image servers. Let me try to see if over the next builds a better expression comes to mind.

For example, the "Edit Query" caption that appears in many dialogs often requires too-long text in various languages (in Turkish, for example, Sorguyu Düzenle), and in such cases translators often use just "Query" (in Turkish, Sorgu). That's slightly cheating UI guidelines that recommend having a verb for command captions, but I don't worry about it.

I came across with this doubt, and the portuguese translation "Editar Pesquisa" reflects this same question. I don' have any problem with shortening to "Editar" only.

Out of curiosity, if you don't mind my asking, do you use the Tools - Edit Localization Filedialog to maintain the file and to add updates?

Yes. It's a superb tool and makes this task really easy . But now that you mentioned this I looked to the original UI file and it seems everything starting with # just vanished. Is this a common behaviour?

adamw


10,447 post(s)
#27-Mar-20 13:54

If you mean lines like:

# <text>

...prior to each section, yes, the tool currently drops them. That has no effect on the localization, because these lines are just comments, but we will perhaps re-add them (to clarify: we won't preserve existing comments you might have made manually, and will re-generate standard comments with simple editing directions instead).

HMS
185 post(s)
#27-Mar-20 14:25

Indeed, that was the case I was addressing. Thanks for the clarification Adam.

Dimitri


7,413 post(s)
#28-Mar-20 02:21

I came across with this doubt, and the portuguese translation "Editar Pesquisa" reflects this same question. I don' have any problem with shortening to "Editar" only.

Just to follow up... The "Edit Query" caption is used on buttons in dialogs such as File - Create - New Map, or File - Create - New Drawing. It also appears with Select and Transform pane templates. Pressing the button launches a Command Window containing SQL that accomplishes in SQL what the dialog does.

If the caption were longer, it would be something like "Open a command window containing the SQL query that accomplishes this task."

But... the caption does not appear on controls when a query is open, to allow you to edit the query. It's true that when you have a query open in a Command Window you can edit it, but it seems to me the primary function of buttons labeled with "Edit Query" is to pop open a query that is being used behind the scenes of a point-and-click dialog.

Therefore, while I can see this going either way, perhaps "Query" might be a better short form than "Edit," because with "Query" you can expect to get a query when you press the button but with "Edit" it might not be clear what is being edited... the contents of the boxes in the point-and-click dialog? The contents of the new map? The idea of automatically generating a query that does what a dialog does is something new, unique to Manifold, so new users might not understand that "Edit" means "Edit the query at work behind the scenes."

Another, more radical, option might be to use a word like "Customize". I tend to lean to either "Query" or "Edit" though, because those words are already frequently translated for various languages in DBMS or other software localizations, so there's almost always an accepted local language form. :-) It's also true that the button is frequently used just to see how the dialog works, as a way to learn SQL, or to grab snippets of functionality for other queries being written, and not so much to customize what the specific template or dialog is doing.

It's interesting to see such questions come up as we zero in on all the fine points of localizations. :-)

HMS
185 post(s)
#28-Mar-20 20:08

I tend to lean to either "Query" or "Edit" though, because those words are already frequently translated for various languages in DBMS or other software localizations, so there's almost always an accepted local language form.

I entirely agree with this. Editar (Edit) may not be the more comprehensive description, but it sums up what that button does. I believe new users will just press "Edit" and quickly find out what that does.

Regarding this translation, it's definitely a process (and a learning curve) leaning progressively towards a more detailed approach. For instance, each time after submitting a new translated UI file, almost instantly, I bump into words or expressions that should have had a better translation. This tends to happen with english words that are used to describe a particular action or subject used also in the common portuguese GIS usage. So please, bear with me :-)

The process I followed at the beginning wasn't particularly stellar: in the first submitted files, given the extreme lack of accentuation of the original file, I felt the need to run some parts of the UI into a software with a Portuguese dictionary. That turned not to be the perfect option, given that instinctively I also translated some words into its direct meaning and, as you stated elsewhere in the forum when addressing the case of regular translators for a task like this, a "normal" translation is far from enough or adequate. We definitely need to go through the details of the regular software usage (going through the different panes, menus, transforms...) to find out a better and suited option. Over the following lines I'll mention a few more words that were still bugging me after the last file. Any thoughts on these will be highly appreciated.

Shape as Polígono

The word polígono (polygon) is fairly common among the portuguese GIS users, so "polígono" is a better translation for "shape" in some transforms. For instance in the "Decompose to Shapes" transform, given the output is decomposed into its constituent shapes, I believe "Decompor em polígonos individuais" (Decompose into individual polygons") would provide a better understanding of the transform.

Edges as Arestas

Edges as "Cantos" is not brilliant ("canto" means specifically corner). I believe "Arestas" is better suited and is also adopted by other softwares such as Photoshop (Sharpen Edges = "Arestas Nítidas")

Median as "Mediana" (mediano is not the right gender for this word). On the other hand, in this example, shape as "forma" is perfect, because it directly refers to the shape of the filter (circle, cross or square).

Branch as Elemento

It's hard to translate "branch". Its english meaning gives you a fast understanding of what you're doing (such as "Decompose in Branches" or "End Current Branch") but to translate this into portuguese is far from obvious. If you're creating lines "End Current Branch" can be "Terminar Ramificação Atual", but if you're creating areas this isn't really appropriate, given that "Ramificação" (or Ramal) are usually applied only to linear elements (like a tram line, for instance). With this in mind, "secção" or "parte" could also be adjusted to this, but they have other meanings adding some confusion. I opted for "elemento" meaning that a single drawing can have more than one constituent element ("Elementos constituintes" is a common expression in the portuguese language), so "Terminar Elemento Atual" seems to work (meaning you're only ending a constituent element, not the entire drawing).

Trace as Vetorizar

In the current file Trace was translated as "rastrear" (in portuguese this means follow a track) and the portuguese word "Vetorizar" is actually used to mean what Trace does.

Contour Areas / Contour Lines = Contornar Áreas / Contornar Linhas

This is a better syntax than "Áreas de Contorno" or "Linhas de Contorno", with the respective options adjusted: Steps as Intervalo (the current "passo" is not correct, given that it means specifically the act of moving a foot to walk) and Decompose to shapes as Decompor polígonos and Decompor linhas respectively.

Merge asJuntar

Merge is currently being translated as Juntar because "fundir" is normally used as melting, and it needs to be different of Unir (Union). Maybe agregar (to aggregate) could be an option but this could also led to some confusion. By now "juntar" seems to be the lesser evil.

Index as Índex

Previously Index was translated as Índice, but given its fonetically proximity and that Índex is also a portuguese word, I believe Índex is a better and more suited translation (the plural is still Índices).

On a different subject, sometimes context helps when searching for a particular transform. Is there a way to rearrange transforms differently than by alphabetical order? This does not constitute a big deal, but I was wondering about it mainly because transforms like Aspect and Slope could make sense being close to each other. This also applies to Median, Major, Minimum, Maximum (probably I could just rearrange this into Valor Máximo, Valor Principal, Valor Mínimo, Valor Médio or Valor Moda)l. Somehow the original UI always seems better organized than the translated :-)

Major as Moda?

In statistics Moda is a portuguese word that represents the most frequent number (the number that occurs the greatest number of times) in an observation. I believe this is what the Major transform does (find the most frequently occurring value found within the pixels covered). Is this a correct assumption?

Also in the previous UI file {productname} was translated into portuguese. That's now corrected and Manifold System is now showing up again in the "About" section. A few more typos were also corrected and this is for sure an upgraded version.

Attachments:
ui.pt.txt

Dimitri


7,413 post(s)
#29-Mar-20 04:16

Wonderful work! Some comments...

Shape as Polígono

The word polígono (polygon) is fairly common among the portuguese GIS users, so "polígono" is a better translation for "shape" in some transforms. For instance in the "Decompose to Shapes" transform, given the output is decomposed into its constituent shapes, I believe "Decompor em polígonos individuais" (Decompose into individual polygons") would provide a better understanding of the transform.

I think you are right for the "Decompose to Shapes" transform, but in other cases, such as "Sample shape" in captions used in layouts it should stay "forma" since in those contexts it refers to lines and points as well as to areas.

Edges as Arestas

Your call. QGIS uses "orlar", but that seems to be an insensitive translation where they use the same word for "edges" in the graph theoretic sense (a terrible word for beginners) as well as "the edge of an image".

By the way, I've attached the current translation file for QGIS if you ever want to search for a word to see how the translator there translated a word. Q uses some words differently (like "edge") so you have to be careful, but it can be a guide to what might be expected, since they apparently used ESRI translations as a guide for various GIS words.

Branch as Elemento

I thing that would be wrong. "Branch" is used in English because of the tree-like hierarchy of the constituent lines that form branched lines and branched areas. Each branch in an area object that has branches (islands, holes in areas) is a boundary line. Because "branch" refers to a linear element, constructions like ramo or ramal or ramificação are spot on.

Another argument against "elemento" is that sooner or later "element" will be used within Manifold as a top level name, meaning "thing" at the level of "component." Personally, although I was OK with it at the time (I might even have been the guy who suggested it... don't remember), I don't much like the word "component" now to mean things like tables, drawings, etc., in a project. I sometimes wish "element" was the word. Words like that which are cognates in many European languages are very valuable things that I suggest should be reserved for high level use, and for constructions very low down that on a few percent of people will ever use.

Merge as Juntar

There are two uses of "merge"... one is in the transforms like Merge Areas and the other in the Merge tool to combine multiple drawings or images into a single drawing or image. Q uses juntar for both. I guess it is the lesser evil. I agree agregar could lead to confusion.

Is there a way to rearrange transforms differently than by alphabetical order?

I think panes use alphabetical order regardless of the order in the ui.pt.txt file. Easy to test: take the default.ui.txt file, rename it to ui.en.txt, rearrange the order in that file and in Tools - Options use that file for localization, to see if the order in the panes is rearranged.

I believe this is what the Major transform does (find the most frequently occurring value found within the pixels covered). Is this a correct assumption?

Yes. For each pixel using a matrix of the given Radius it finds the most frequently occurring value found within the pixels covered by the matrix

You're doing wonderful work. The translation as it started in this thread was clearly student work, but you're polishing it into something very professional!

Attachments:
qgis_pt_PT.txt

HMS
185 post(s)
#29-Mar-20 16:57

Shape as Polígono

The word polígono (polygon) is fairly common among the portuguese GIS users, so "polígono" is a better translation for "shape" in some transforms. For instance in the "Decompose to Shapes" transform, given the output is decomposed into its constituent shapes, I believe "Decompor em polígonos individuais" (Decompose into individual polygons") would provide a better understanding of the transform.

I think you are right for the "Decompose to Shapes" transform, but in other cases, such as "Sample shape" in captions used in layouts it should stay "forma" since in those contexts it refers to lines and points as well as to areas.

In that particular case "Sample shape" was translated as "formato da amostra" ("formato" is also a synonym for "forma"), but given that "formato" is also used in other examples such as "Invalid file format", "forma" is indeed a better option.

In this same topic, in the register pane the "Sample width / position:" translation was being truncated by lack of space in the pane, so I opted to reduce it to "Largura / posição:" only. I'm sure there are a few more cases where these sort of "truncated" expressions appear.

Edges as Arestas

Your call. QGIS uses "orlar", but that seems to be an insensitive translation where they use the same word for "edges" in the graph theoretic sense (a terrible word for beginners) as well as "the edge of an image".

By the way, I've attached the current translation file for QGIS if you ever want to search for a word to see how the translator there translated a word. Q uses some words differently (like "edge") so you have to be careful, but it can be a guide to what might be expected, since they apparently used ESRI translations as a guide for various GIS words.

I believe "aresta" is better than "orla". Thanks for the QGIS file. In fact, each time I have some difficulty regarding a particular word/expression I try to run a few different softwares while trying to figure out what the norm is. In this process I found out that QGIS, in particular, has some expressions that are errors in itself, such as "Convert raster to vector lines" translated as "Converter linhas raster para vetores" (this means "convert raster lines to vectors").

Branch as Elemento

I thing that would be wrong. "Branch" is used in English because of the tree-like hierarchy of the constituent lines that form branched lines and branched areas. Each branch in an area object that has branches (islands, holes in areas) is a boundary line. Because "branch" refers to a linear element, constructions like ramo or ramal or ramificação are spot on.

Another argument against "elemento" is that sooner or later "element" will be used within Manifold as a top level name, meaning "thing" at the level of "component." Personally, although I was OK with it at the time (I might even have been the guy who suggested it... don't remember), I don't much like the word "component" now to mean things like tables, drawings, etc., in a project. I sometimes wish "element" was the word. Words like that which are cognates in many European languages are very valuable things that I suggest should be reserved for high level use, and for constructions very low down that on a few percent of people will ever use.

I agree. It was by far the least convincing translation I submitted. Given the tree-like hierarchy associated with branch, I went back to "Ramificação". In my opinion, it's better than "ramal" or "ramo" and its meaning is "subdivision of something; branch", so I believe so far it's the best option for this case.

Is there a way to rearrange transforms differently than by alphabetical order?

I think panes use alphabetical order regardless of the order in the ui.pt.txt file. Easy to test: take the default.ui.txt file, rename it to ui.en.txt, rearrange the order in that file and in Tools - Options use that file for localization, to see if the order in the panes is rearranged.

I confirm panes uses alphabetical order regardless of the order in the UI file.

Another translation that was escaping my radar was related to the word "shift". It was always translated as "mudar" since the first UI file but it needed a little refinement. "Deslocar" was instead adoptedin the translation of "Shift|Geom:|Shift X:|Shift Y:" as in "Deslocar|Geom:|Deslocar X:|Deslocar Y:", while in cases such as "Switch to Window" it remains "Mudar para Janela".

I believe with a few more tweaks will be reaching a more "refined" result that we can use for the next builds. Attached you can find the UI with all the mentioned adjustments updated.

Attachments:
ui.pt.txt

HMS
185 post(s)
#08-Apr-20 21:37

Hi Dimitri, attached you can find a new Portuguese Localization file for the 9.0.171.2 build.

Besides the new features for the latest build (btw the join dialogue is wonderfull!), some corrections were made since the last file submitted (mostly regarding accentuation and typos). I believe we're going in the right direction ;)

Attachments:
ui.pt.txt

HMS
185 post(s)
#17-Apr-20 17:32

Hi Dimitri, with a little delay here's the new Portuguese Localization file for the 9.0.171.3 build (a few corrections were made regarding the previous versions and the new features of the last build are now translated).

Attachments:
ui.pt.txt

Dimitri


7,413 post(s)
#17-Apr-20 18:38

Looks really super! Thanks.

JPMapas
46 post(s)
#22-Apr-20 17:18

Hello,

Congrats for the effort of transelate the UI to Portuguese!

Obrigado!

HMS
185 post(s)
#28-Apr-20 13:06

Hi JPMapas it's great to see another portuguese speaker in this forum.

De nada!

HMS
185 post(s)
#28-Apr-20 13:04

Hi Dimitri, earlier on I incorrectly confirmed that the transform pane was organized alphabetically, but my assumption turned out to be not entirely accurate.

Recently, while appliying Order Ascending/Descending in a table I found out that currently the alphabetical rule is not applying correctly to the portuguese language, given that any character featuring a graphic accentuation like <´> <`> <^> <~> <ç> is only shown after <z>.

I submitted a suggestion featuring what the general rule should be.

adamw


10,447 post(s)
#28-Apr-20 16:23

The Order Ascending / Order Descending commands in a table window sort using language-neutral rules.

To sort using rules specific to a particular language, you currently have to use a query with ORDER BY and COLLATE, eg:

--SQL9

SELECT * FROM <tableORDER BY <field> COLLATE 'pt-PT, nocase';

We should perhaps add means to make Order Ascending / Order Descending also use language-specific rules, agreed.

HMS
185 post(s)
#28-Apr-20 16:30

Hi Adam, thanks for the info and for the query.

That addition would be very much welcomed!

HMS
185 post(s)
#13-May-20 17:02

Hi Dimitri, attached you can find a new Portuguese Localization file for the 9.0.172.0 build.

Attachments:
ui.pt.txt

Dimitri


7,413 post(s)
#13-May-20 17:39

Beautiful!

HMS
185 post(s)
#28-May-20 20:08

Hi Dimitri, a bit overdue here's the new Portuguese Localization file for the 9.0.172.1 build.

There are some changes regarding previous versions regarding some transform templates. For instance, Curvature (Plan) is now translated as "Curvatura (Plan)" - "Plan" for planform - instead of the previous "Curvatura (Plano)" that was misleading; and "reverse line", now translated as "inverter linha", was wrongly translated before as "reverter linha" (in portuguese "reverter" has a different meaning of "inverter" being this last one the right meaning for this transform). I'm sure a few more changes were done, and a few more adjustments will be made while continuing to work with M9.

Attachments:
ui.pt.txt

HMS
185 post(s)
#10-Jun-20 16:21

Hi Dimitri, again a bit overdue, here's the Portuguese Localization file for the 9.0.172.2 build.

Attachments:
ui.pt.txt

adamw


10,447 post(s)
#11-Jun-20 07:17

That's really great, thank you!

We understand we aren't making it easy to keep localizations up to date with all the cutting edge builds. We promise, however, that we are constantly thinking about localizations when designing the UI, and that whenever we can choose to do something that reduces the impact on localizations - eg, use an icon instead of a caption, or use the exact same string to denote the same thing across panes and dialogs - we do this.

Nonetheless, there's quite a bit of effort left to keep a localization up to date and especially to keep it good. There's an inside joke in programming that there are only two difficult things regarding it - creating a caching policy that doesn't fail in some way and naming things. That's only a half-joke, however, because naming thins is indeed really hard. And localizers have it even more difficult than programmers, given that the UI is read by many more people than program code and that people reading it have more diverse backgrounds. So, we really appreciate all the effort from you and others that is being put into this work.

Thank you!

KlausDE

6,410 post(s)
#11-Jun-20 07:58

We understand we aren't making it easy to keep localizations up to date with all the cutting edge builds.

Not really. Adding new UI elements spots the new funcionality in digestable chunks.


Do you really want to ruin economy only to save the planet?

rk
621 post(s)
#11-Jun-20 10:53

I agree. Incremental changes do not take too much time. Reguralry reviewing the file gives the opportunity to tweak existing translations.

I'm not using Edit Localization File dialog. I have my own workflow.

* diff old default.ui.txt with new default.ui.txt

* manually copy new/edited key=values and delete removed key=values from ui.XX.txt

* diff new default.ui.txt with updated ui.XX.txt.

* find identical (unlocalized) rows. Check that all keys are matching etc.

Attachments:
translate.png
translate2.png

HMS
185 post(s)
#11-Jun-20 13:21

We understand we aren't making it easy to keep localizations up to date with all the cutting edge builds.

Not really. Adding new UI elements spots the new funcionality in digestable chunks.

I agree with this. The last delays are more related to my workflow (and overload) over the last month than the time consumed by updating the localization file. The builds are fantastic for translating the UI in small steps and the time between each new build is great to review and improve the translation file while working with M9. The "Edit Localization File" tool continues to work smoothly and usually it's a quick process to update the file. Please keep the new builds coming ;)

HMS
185 post(s)
#11-Jun-20 18:07

Portuguese Localization file for the 9.0.172.3 build.

Attachments:
ui.pt.txt

HMS
185 post(s)
#28-Dec-20 16:11

Hi Dimitri, here's the new PT localization file for the 9.0.173 build.

After some changes over the last builds regarding mostly transform templates designations I had some doubts that are worth of a second opinion, if possible, namely:

  • Split (previously "decompose") - in fact it was easier to translate this template as "decompor", but after some time I believe "split" is best translated as "separar" (separate), also aggregating the meaning of the "split with" operation;
  • Clean - I had some struggles with this template, specially with the "clean - fill Z", as filling something with new values felt a little bit contradictory with the "clean" translation. Instead of the linear translation for "clean" (limpar) I opted for "refinar" (refine);
  • Slope - there is some redundancy in the "slope" template translation, given that slope also applies to the specific operation "slope". Altough I understand that this template applies to slope related transforms, the "aspect" operation could be somehow lost in translation. This template is now translated as "relevo" (relief).

  • Tile - after reasoning about this translation since the earlier builds where "tile" was translated as bloco (block), I believe "mosaico" (as mosaic) could provide a better translation for the "tile" meaning;

Attachments:
ui.pt.txt

JPMapas
46 post(s)
#28-Dec-20 17:07

Olá,

Some considerations about the translation:

  • Split (previously "decompose") - translated as "separar" (separate), AGREE;
  • Clean - I had some struggles with this template, specially with the "clean - fill Z", as filling something with new values felt a little bit contradictory with the "clean" translation. Instead of the linear translation for "clean" (limpar) I opted for "refinar" (refine), IT'S HARD TO SAY...;
  • Slope - This template is now translated as "relevo" (relief). MAYBE "VERTENTE" OR "DECLIVIDADE"
  • Tile - I believe "mosaico" (as mosaic) could provide a better translation for the "tile" meaning, AGREE;

Regards

HMS
185 post(s)
#28-Dec-20 20:08

Olá JP,

thanks for your thoughts and suggestions for the PT localization file, they are really appreciated. Regarding the examples mentioned before:

- clean: this one is definitely a work in progress, but it doesn't feel like the obvious "clean" translation (limpar) could be adequate to define an operation such as filling a table with Z values. In the linear translation "limpar" could be taken as a sort of wipe action and I tend to search for a synonym that could have a similar meaning without such a strong relation with the wiping action. Refinar (refine) implies an action, like improving something, that encloses more than wiping out the value of a table, for instance. Of course, any more thoughts on this would be appreciated.

- slope: "vertente" seems to be a nice fit for slope and better than "relevo". Declividade is also a synonym for declive, and a nice suggestion, but it could be somewhat redundant. Given that the slope template relates to hillsides, I'm tending to believe that "vertente" is a better translation.

Also, this one is an old question (somewhere in the first comments of this thread), but let me know your thougths on the style panel. After months of translating border as "limite" (it didn't feel like "borda" could be an adequate translation) while trying to adopt a more "universal" pt translation, I changed my mind about this and it's now translated again as borda, in line with some "pt-br" software, as a synonym for "moldura" ou "margem".

Attached I'm sending a new ui.pt file with "vertente" instead of relevo and a few corrections more.

Attachments:
ui.pt.txt

JPMapas
46 post(s)
#29-Dec-20 10:21

Olá,

Some comments:

- clean: This is a very tricky word to translate to Portuguese...

- slope: "vertente" seems to be a nice fit for slope and better than "relevo". Declividade is also a synonym for declive, and a nice suggestion, but it could be somewhat redundant. Given that the slope template relates to hillsides, I'm tending to believe that "vertente" is a better translation. AGREE

Also, this one is an old question (somewhere in the first comments of this thread), but let me know your thougths on the style panel. After months of translating border as "limite" (it didn't feel like "borda" could be an adequate translation) while trying to adopt a more "universal" pt translation, I changed my mind about this and it's now translated again as borda, in line with some "pt-br" software, as a synonym for "moldura" ou "margem". I LIKE "LIMITE"...

Regards

geozap
264 post(s)
#29-Dec-20 12:20

I am not a Portuguese speaker, but maybe you could use some equivalent of "tidy up", if such exists in pt language. "Tidy up" doesn't mean "Clean", but "Clean" transoformation tidies up drawings.

HMS
185 post(s)
#29-Dec-20 12:40

Hi geozap, thanks for the suggestion. It'd be great if we had a "tidy up" equivalent but it points out a good direction for this word. If I'm not mistaken, tidy up is closer to "arrumar" (something like "clean up"), but arrumar feels a little bit strange in this context. That why I went for "refine" in the ui file in the sense of improving/perfecting drawings. Probably "aperfeiçoar" (to improve, perfect or meliorate) could also be a good translation for this template.

JPMapas
46 post(s)
#30-Dec-20 11:54

Olá,

"Tidy up" means in portuguese "arrumar"...

So... thinking in the tool, maybe "ajustar"... "aperfeiçoar" it's not bad...

HMS
185 post(s)
#30-Dec-20 16:11

Olá JP, "ajustar" seems to be a better option indeed. Let's try with this one.

Attached there's the updated version of the ui.pt file.

Attachments:
ui.pt.txt

JPMapas
46 post(s)
#01-Jan-21 18:31

Hello,

I'm going to test.

Bom Ano Novo!

tjhb
10,094 post(s)
#02-Jan-21 05:50

Look, this is getting silly.

Does "Clean" make sense in English? No.

It has been chosen by devs whose first language is not English.

This applies not just to individual words, but to the subdivisions.

Probably none of it is what a native speaker of English would choose.

Does it matter? Not much.

What it means, though, is that translators to further languages shouldn't worry very much about getting it "right".

It may well not be "right" in English. The English is not something to match.

Just do what you are comfortable with!

HMS
185 post(s)
#02-Jan-21 19:37

Hi Tim, the goal behind the portuguese localization file is to translate it into words that correctly represent the original file's intent, not so much the "right" english. Sometimes it's a direct translation and sometimes it's a totally different word or expression that represents the same action in portuguese, but getting comfortable with the result represents a great part of this process. So I believe we're on the same page regarding this topic.

The translated file already has plenty of words/expressions that are not a linear translation of the original file, but from time to time there are a few ones that are not easy to translate into a GIS context (other GIS with a portuguese translation already implemented in the community are also taken in consideration). That's what happend with "clean", where I do understand the set of actions behind this transform but the right word didn't "pop-up" and I was definitely not comfortable with my first translation. Both words are far from the original "clean", from "refinar" (the first take on "clean") to "ajustar" (the last one) it was a significant leap into a better understanding (in portuguese) of what's behind this transform. It may seem as a tiny detail debating a single word, but I believe it's worth the effort as the portuguese localization file already benefited from this small interchange.

HMS
185 post(s)
#18-Jan-21 17:03

Portuguese Localization file for the 9.0.173.2 build.

Attachments:
ui.pt.txt

HMS
185 post(s)
#18-Mar-21 15:57

Portuguese Localization file for the 9.0.173.4 build.

A few changes since the last localization file: "query" and "tile" are now kept in english. Query: given the common usage of the word "query" across other platforms (even in portuguese SQL manuals), query is not translated (sometimes only as "consulta" for a description purpose). Tile: given the default "tile" field name, not translating "tile" seems more adequate to avoid confusion when using expressions with tile functions.

Attachments:
ui.pt.txt

HMS
185 post(s)
#21-Apr-21 15:00

Portuguese Localization file for Manifold System 9.0.174.0 build.

Attachments:
ui.pt.txt

HMS
185 post(s)
#13-Oct-21 12:36

Portuguese Localization file for Manifold System 9.0.175.3 build.

I wonder if a cleanup of this thread would be possible or if it would be better to make a new thread?

Attachments:
ui.pt.txt

Dimitri


7,413 post(s)
#13-Oct-21 12:45

it would be better to make a new thread?

I think starting a new thread.

Muito obrigado por uma tradução maravilhosa!

HMS
185 post(s)
#13-Oct-21 13:30

OK, I'll do that with the next ui file and I'll try to upload the translation files more frequently.

Also, thank you for your perfect Portuguese sentence, but I fear it is far too complimentary.

Dimitri


7,413 post(s)
#13-Oct-21 15:30

Ah, the compliment is real but, alas, the sentence is not mine: thanks go out to the DeepL translator. :-) I strongly recommend downloading and using their tiny Windows app.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.